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

Daniel Phillips
2004-07-27T05:56:29Z

On Tuesday 27 July 2004 00:07, Nick Piggin wrote:
> But a PF_MEMALLOC userspace task is still useful.

Absolutely. This is the route I'm taking, and I just use an ioctl to flip the
task bit as I mentioned (much) earlier. It still needs to be beaten up in
practice. The cluster snapshot block device, which has a relatively complex
userspace server, should be a nice test case.

> >The PF_MEMALLOC flag is inherited down a call chain, not across a pipe or
> >similar IPC to user space.
>
> This is no different in kernel of course.

I was talking about in-kernel. Once we let the PF_MEMALLOC state escape to
user space, things start looking brighter. But you still have to invoke that
userspace code somehow, and there is no direct way to do it, hence
PF_MEMALLOC isn't inherited. An easy solution is to have a userspace daemon
that's always in PF_MEMALLOC state, as Andrew mentioned, which we can control
via a pipe or similar.

> You would have to think about
> which threads need the flag and which do not. Even better, you might
> aquire and drop the flag only when required.

Yes, that's what the ioctl is about. However, this doesn't work for servicing
writeout.

> I can't see any obvious problems you would run into.

;-)

Regards,

Daniel