Re: [rfc][patch] remove racy sync_page?

[Nick Piggin <nickpiggin@yahoo.com.au>]

Linus Torvalds wrote:
> On Wed, 31 May 2006, Nick Piggin wrote:
>
> > Now having a mechanism for a task to batch up requests might be a
> > good idea. Eg.
> >
> > plug();
> > submit reads
> > unplug();
> > wait for page
>
>
> What do you think we're _talking_ about?

Plugging. Emphasis on task.

> What do you think my example of sys_readahead() was all about?
>
> WE DO HAVE EXACTLY THAT MECHANISM. IT'S CALLED PLUGGING!

It isn't exactly that. I'm thinking per-task rather than per-queue might
be a better idea because a) you don't know what else is putting requests
on the queue, and b) the point where you wait is not always the best place
to unplug.

> > I'd think this would give us the benefits of corse grained (per-queue) 
> > plugging and more (e.g. it works when the request queue isn't empty). 
> > And it would be simpler because the unplug point is explicit and doesn't 
> > need to be kicked by lock_page or wait_on_page
>
>
> What do you think plugging IS?
>
> It's _exactly_ what you're talking about.

Yes, and I'm talking about per-task vs per-queue plugging (because I want
to get rid of the implicit unplug, because I want to make lock_page & co
nicer).

> And yes, we used to have 
> explicit unplugging (a long long long time ago), and IT SUCKED. People 
> would forget, but even more importantly, people would do it even when not 

I don't see what the problem is. Locks also suck if you forget to unlock
them.

> needed because they didn't have a good place to do it because the waiter 
> was in a totally different path.

Example?

> The reason it's kicked by wait_on_page() is that is when it's needed.

Yes, you already said that, and I showed cases where that isn't optimal.

I don't know why you think this way of doing plugging is fundamentally
right and anything else must be wrong... it is always heuristic, isn't
it?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/