Re: [PATCH 0/2] pdflush fix and enhancement

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). If so, does the barrier go after the
read, or before? (Thanks for not laughing, however grins are allowed)



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.



I was thinking about a patch that would go both directions - forward and
reverse depending upon, say, a bit in jiffies... Certainly not perfect,
but a bit more fair.

Better a real RNG. But such probalistic schemes unfortunately tend to drive
benchmarkers crazy, that is why it is better to avoid them.


Nod, but that's ok. Having been one for several years I can truthfully
say that benchmarkers are a little crazy anyways... :-)


I suppose you could just keep some state per fs to ensure fairness.


Nod, this would be ideal.

-PWM

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [PATCH] Document Linuxs memory barriers [try #2]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Re: I/O memory barriers vs SMP memory barriers
    ... There's actually three different cases of interest on ARM: ... direct-mapped and vmalloced kernel memory ... on SMP systems, and just a compiler barrier on UP systems. ... you _would_ need hardware barriers for. ...
    (Linux-Kernel)
  • Re: locking and cache coherence
    ... implementation contain the necessary memory barriers. ... synchronization with respect to the pthread locking, etc., semantics. ... occur after all stores within the locked section. ...
    (comp.programming.threads)
  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... Just make sure everybody knows the basics of barriers, ... can apply that knowledge to atomic_t and all other lockless memory ... for atomic types. ... So much explicit sprinkling of "forget" looks ugly. ...
    (Linux-Kernel)
  • Re: lock statement questions
    ... releasing a lock counts as a volatile write. ... into a register (forcing the equivalent of a volatile read). ... Memory barriers most certainly *are* involved - in the specification. ...
    (microsoft.public.dotnet.languages.csharp)