Messages in this thread | | | Date | Thu, 01 Jun 2006 00:57:34 +1000 | From | Nick Piggin <> | Subject | Re: [rfc][patch] remove racy sync_page? |
| |
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/
| |