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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux