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

Nick Piggin
2006-05-31T15:34:07Z

[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