Avoiding raw-io is not a good solution. Remapping would be a performance
hit anyway (other than having other problems, namely, you might not find
a page to remap to). Remapping in just the swap code is acceptable, but
probably not for other cases (like rawio).
>
> I guess big databases uses the shm memory as cache. And I guess they use
> raw-io to fill the shm memory with proper data. Am I right about this? If
Yes, I believe so ...
> so I can't choose (4). And since I would like to use the bigmem as shm
> memory I would like to avoid also (5).
>
> (3) looks dirty and add a performance hit in the shm_nopage hander.
>
> (2) looks dirty and slow due the SMP tlb flushes.
>
> (1) looks clean and efficient (100% efficient in the DMA case!) but it
> breaks all drivers out there... :(((
>
> Theorically the cleanest solution would be (1) but I don't know if this
> will be a good choice on the long run (theorically on 2038 we won't need
^^^ What is 2038?
> CONFIG_BIGMEM anymore...).
Part of the reason my bigmem patch for 2.2 has been implemented the
way it is, is so that drivers don't break. I think 2.3 is the place to
teach the kernel and drivers that all of memory is not directly mappable.
Specially, if we hope to put in the PAE/36bit stuff in anytime. Yes,
that means fixing drivers. Of course, that's just my opinion ...
>
> Right now I temporary applyed solution (0): the patch at the top of this
> email so if you want to use raw-io on anonymous or shm memory you'll have
> to recompile with CONFIG_BIGMEM not set.
>
> Comments? (very welcome :)
>
Once you can get resolution and decision on the driver issue, bigmem
pages can also exist in the page cache. And kmalloc could also use
bigmem pages for holding kernel data structures ...
Kanoj
> Andrea
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/