Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30 | Date | Mon, 12 Jul 2004 22:19:17 -0400 |
| |
Hi Andrew,
On Monday 12 July 2004 16:54, Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > I don't see why it would be a problem to implement a "this task > > facilitates page reclaim" flag for userspace tasks that would take > > care of this as well as the kernel does. > > Yes, that has been done before, and it works - userspace "block drivers" > which permanently mark themselves as PF_MEMALLOC to avoid the obvious > deadlocks. > > Note that you can achieve a similar thing in current 2.6 by acquiring > realtime scheduling policy, but that's an artifact of some brainwave which > a VM hacker happened to have and isn't a thing which should be relied upon.
Do you have a pointer to the brainwave?
> A privileged syscall which allows a task to mark itself as one which > cleans memory would make sense.
For now we can do it with an ioctl, and we pretty much have to do it for pvmove. But that's when user space drives the kernel by syscalls; there is also the nasty (and common) case where the kernel needs userspace to do something for it while it's in PF_MEMALLOC. I'm playing with ideas there, but nothing I'm proud of yet. For now I see the in-kernel approach as the conservative one, for anything that could possibly find itself on the VM writeout path.
Unfortunately, that may include some messy things like authentication. I'd really like to solve this reliable-userspace problem. We'd still have lots of arguments left to resolve about where things should be, but at least we'd have the choice.
Regards,
Daniel - 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/
| |