Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

[Daniel Phillips]

Hi Andrew,

On Monday 12 July 2004 16:54, Andrew Morton wrote:
> Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/