lkml.org 
[lkml]   [2008]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] pdflush fix and enhancement
On Wed, Dec 31, 2008 at 09:08:26AM -0700, Peter W. Morreale wrote:
> On Wed, 2008-12-31 at 14:27 +0100, Andi Kleen wrote:
> > > I say most because the assumption would be that we will be successful in
> > > creating the new thread. Not that bad an assumption I think. Besides,
> >
> > And that the memory read is not reordered (rmb()).
> >
>
> At the risk of showing my b*tt here... I'm not very clear on memory
> barriers, is this necessary even inside a critical region? (recall
> we're protected by the spin lock).

You're right the implied barriers in the spinlock are probably enough.
Never mind.

> If so, does the barrier go after the
> read, or before? (Thanks for not laughing, however grins are allowed)

Before.

BTW on x86 it's a nop either way, but not on all other architectures.

>
>
> >
> > Ok it probably needs some kind of feedback mechanism.
> >
>
> Actually, I tend to think we need an entirely different approach to
> flushing, please see my post to David Chinner which outlines some
> thoughts. Basically a flushing heuristic that takes into account the
> characteristics of the various block devices.

Ideally discovered at runtime (e.g. by watching queue lengths/service
times etc.) though. Otherwise the kernel would need to have knowledge
about the properties of all kinds of devices.

-Andi
--
ak@linux.intel.com


\
 
 \ /
  Last update: 2009-01-01 14:08    [W:0.044 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site