> I don't think we want a integer number, we want a "immobility" flag, which
> says that any operations on that VMA have to be done on the whole area.
> Then it's up to the device driver and the architecture-specific parts to
> decide what kind of "immobile" blocks we can have.
the 4m issue is i think conceptually a granularity thing. Theres nothing
wrong with unmapping the middle 4M of a 12M framebuffer mapping, no matter
how rare it would be. In this case a 4M mapping is not very 'special',
it's mapped by the page tables. It's the mapping definition that got
changed, and this new mapping definition seems to be present in all/most
modern CPUs. This issue will be even more visible if we ever want to allow
to map normal memory in such a way. (It's not just number-crunchers, i'd
be _really_ curious wether say Oracle's IPC SHM server memory area, which
typically is unswappable and has a granularity of 1M and a size of 10-100M
or more, would benefit from large-page mappings, TPC-wise)
but 4M real-memory mappings raise other serious issues like how do we
allocate/deallocate (swap?) those monsters.
> For example, some hardware allows special memory regions that aren't
> mapped by page tables at all, and don't even have to be powers of two in
> size. I don't want the normal Linux memory management to know about them,
> but I'd find it acceptable to have a "don't touch me" flag.
i think this is a separate problem from 4M pages, it calls for a
VM_SPECIAL flag. But i agree that mapping PCI memory is a border case, and
'high memory' is special cased already:
if (MAP_NR(page) >= max_mapnr)
return 0;
this could be catched on the vma level already, so it would speed up X.
(because otherwise we'd scan the PCI framebuffer vma many times without
any chance to swap it out, if my reading is correct)
-- mingo
-
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/