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

[Daniel Phillips]

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
-
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/