[...]
> 2) I'm sleeping (or might sleep) on an operation referring to a vma,
> nobody try to remove it from under me.
wouldnt it be a simpler design if we enforced atomicity of VMA usage? I'm
still shocked by the simplicity of the dentry tree ;)
i'm trying to list the major spots where we sleep while holding a vma
context:
1- implicit gfp()'s in all the [pte|pmd|pgd]_alloc()'s
2- single-page pagefaults
3- page table setup (copy_page_range())
4- etc.
so the scheme would be to do instead of this in case of a page fault:
- fault
- look up vma
- dive into the MM context, notice that a page is missing
- lock necessary part of the MM context
- allocate page
- sleep waiting for the page
- insert page into MM context
- unlock context
proposed scheme:
- fault
1: - look up stuff from MM context
- try to get a page _sleepless_
- got it ===> cool, insert, return
- nope ===> oops, no page, have to sleep, kick mem subsystem & add
some mem pressure
- after sleeping, goto 1
in this new scheme, it's perfectly legal and desired to say have 10
clone's trying to allocate 10 pages for the very same VM address. The
first one will succeed, and these 10 allocations will add enough pressure
to the mem subsystem so that it goes faster ... speed of completion
depends on the number of waiting threads. Automagic object-priorites,
whee.
about threads looping forever in the goto loop: well, infinit system load
causes infinit latencies anyway? :)
is this very broken?
-- mingo