> I think "release_segments()" is a user-mode thing. And who knows, on some
> architectures it could block.
>
> But hey, that was not really much of a decision, it just happened.
>
> > Non-obvious difference: destroy_context() is gone in your version. Methink
> > we'ld better leave it around... Probably it's a question to DaveM - all
> > non-trivial context stuff sits in sun4c.c and srmmu.c.
>
> I didn't want to leave it there: we still continue to use the context,
> it's just lazy now. So I suspect destroy_context should go into the
> __mmdrop() part,
Oh, sure. In my variant mmput() is more or less the same as your
mmdrop() - I prefered to lambda the if(...) exit_mmap() out of it instead
of creating a new function. Indeed it should go into the non-blocking
part.
> but without any deeper knowledge of any architecture that
> needs it I didn't want to make the decision.
From my reading of sun4c and srmmu code it looks like a
fixed-sized cache with LRU. So dropping it means an LRU pollution. Not too
nice, but probably bearable. I'ld really like to hear comments from sparc
folks on that, though...
> Good that you pointed it out, though. There are likely to be other
> architecture issues that may need tweaking.
>
> > Another thing: checks in binfmt_{elf,aout,whatnot}.c (is it dumpable?)
> > should go into the top-level code. Otherwise we'll spend the eternity
> > trying to resync all copies. I'll do it if you have no objections.
>
> Sure.
>
> > And it
> > starts to smell like we would be better off with a kernel/mm.c instead of
> > all having the context-related stuff scattered over the tree. Comments?
>
> What kind of stuff?
mm_alloc(), mmput(), mm_exit(), exec_mmap(), copy_mm(). BTW, I'ld rather
add mm_exit() into the kernel_thread(). And let those who really want a
non-lazy behaviour call exec_mmap(). Methink they are in serious minority.
Let's see... Oho...
a) on ARM - something called 'ecard' launches a thread that obviously
assumes that it's a sole owner of address space. Even CLONE_VM is a bloody
murder here. It *must* call exec_mmap() or equivalent - sucker plays with
its PGD. (arch/arm/kernel/ecard.c)
b) drivers/macintosh/mediabay.c - pure kernel thread, AFAICS ought to call
exit_mm() but doesn't bother to do it
c) drivers/ap1000/ddv.c - AFAICS the same as situation as with (b).
d) drivers/char/h8.c - ditto.
e) scsi_error_handler - hell knows. SCSI layer is not my favorite
reading...
f) kmod and baycom_epp - both do exec() (insmod and eppconfig resp.) and
none of them has a chance in hell to get an non-shared context. So
equivalent of exit_mm() will be done anyway.
The rest of the lot (and there *is* a lot) does explicit
exit_mm(). IMO it means that we'll have to expose exec_mmap() (ecard stuff
- it *does* need a private PGD) and that we would be much better with lazy
threads as default. Those who need a non-lazy behaviour can ask for it
themselves. If they need it they probably need a separate context anyway.
And we are talking about 4 cases when it *might* be needed.
-
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/