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

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

[trimming CC list]

Linus Torvalds wrote:
> 
> On Thu, 1 Jun 2006, Nick Piggin wrote:

>>
>>Example?
> 
> 
> Pretty much all of them.
> 
> Where do you wait for IO?
> 
> Would you perhaps say "wait_on_page()"?
> 
> In other words, we really _do_ exactly what you think we should do.

I still think the submitter should plug before they start a set of
requests (the submitter currently does not plug, the queue does when
it empties), and unplug when it has finished submission (not when a
process next waits, because that is suboptimal for asynch IO).

When you do this, the plug/unplug should become simple like locks too.

You're really keen on unplugging at the point of waiting. I don't get
it.

> 
> 
>>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?
> 
> 
> A _particular_ way of doing plugging is not "fundamentally right". I'm 
> perfectly happy with chaning the place we unplug, if people want that. 
> We've done it several times.

OK.

> 
> But plugging as a _concept_ is definitely fundamentally right, exactly 
> because it allows us to have the notion of "plug + n*<random submit by 
> different paths> + unplug".

Yeah the concept isn't bad. I think the queue based implementation, and
unplug at wait time isn't great.

> 
> And you were not suggesting moving unplugging around. You were suggesting 
> removing the feature. Which is when I said "no f*cking way!".

It may be a good concept but if it doesn't help, then removing it is a good
idea too ;) Now I've been told it does help, so instead of removing it I
suggest changing it. Just exploring ideas.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com