Yes, that is fine.
>2) If you need to do decompression on a cpu you check the array entry
> for that CPU and if is NULL you vmalloc() the decompression buffers once
> for that CPU. This avoid vmalloc() overhead for each read.
The vmalloc() sleeps and by the time you get control back you are executing
on a different CPU. Ooops. The only valid way of treating per-cpu data is:
- disable preemption
- get the cpu number = START OF CRITICAL SECTION: no sleep/schedule allowed
- do work using the cpu number
- reenable preemption = END OF CRITICAL SECTION
The only thing that could possibly be used inside the critical region is
kmalloc(GFP_ATOMIC) but we are allocating 64kiB so that is not an option.
(It would fail very quickly due to memory fragmentation, the order of the
allocation is too high.)
>3) Any allocated buffers are freed in the same manner they are now -
> when the last compressed volume is unmounted. There may be some or
> all entries that are still NULL.
>
>This also avoids allocating buffers when there are no files which are
>actually compressed.
True it does, but unfortunately it doesn't work. )-:
Best regards,
Anton
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown-- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/