Re:[PATCH] Implement barrier support for single device DM devices

Re:[PATCH] Implement barrier support for single device DM devices

[Mat]

Hi Andi,

any news on this patch and when it will get included in mainline / linus' tree ?

I believe this will gain lots of people time savings with no side-effects :)

(I haven't tried it out yet but will in the near future, so if there's
a new version of it, please let people know)

Many thanks in advance

Mat

Re: Fwd: [PATCH] Implement barrier support for single device DM devices

[Mat]

Hi Andi,

any news on this patch ?

from what I saw it isn't included in mainline yet, if it is already
please point to the kernel-config option where to enable it

there are some serious problems with interactivity / GUI access during
heavy flush, write operations; especially on amd64/X64:
http://forums.gentoo.org/viewtopic-t-482731.html

I'm not sure if it's possible but I believe it could also be related
to filesystems switching to synchronous writes (non-barrier
write-mode) when the underlying partition is a LUKS-partition and
therefore
decreasing performance (I'm not a kernel-hacker so I don't know if
there's a possible correlation here)

some factors I noticed having an impact on that are:

- CFS (the cpu scheduler)
  # if echo 1 > /sys/devices/system/cpu/sched_mc_power_savings is enabled
  # and group scheduling enabled
  it's very noticable, sometimes under heavy load the output on the
monitor hardly changes anymore and the box also hardly reacts to input
  on my hardware the best interactivity under high load so far was
with a 2.6.24-based kernel (2.6.24-zen3/4) after and before that with
CFS everything was average and not very interactive (YMMV)
- the i/o scheduler hardly makes a change
- elder boxes with PCI (non-PCIe) can be "fixed" with some latency-tweaks:
  setpci -v -d *:* latency_timer=b0

   setpci -v -s 02:00.0 latency_timer=40
   setpci -v -s 00:1f.2 latency_timer=40

  setpci -v -s 02:00.1 latency_timer=40
  setpci -v -s 00:1f.1 latency_timer=40

   #maximize latency timers for network and audio, allowing them to transmit
  #more data per burst, preventing buffer over/underrun conditions
  setpci -v -s 00:1b.0 latency_timer=ff
  setpci -v -s 03:00.0 latency_timer=ff
  setpci -v -s 04:00.0 latency_timer=ff
- for me this doesn't occur / didn't occur with the RT-kernel and
hardirq, softirq, preemptive rcu enabled

Many thanks in advance

Regards

Mat



On Thu, Sep 11, 2008 at 6:46 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Thu, Sep 11, 2008 at 04:13:39PM +0200, Mat wrote:
>> any news on this patch and when it will get included in mainline / linus' tree ?
>
> I think Alasdair rejected it in the end (?) He tried to explain me why at OLS,
> but as far as I remember I didn't understand his reasoning. It had something
> to do with stack consumption, but afaik the patch doesn't
> increase stack consumption.
>
> Cc him for clarification.
>
>> I believe this will gain lots of people time savings with no side-effects :)
>>
>> (I haven't tried it out yet but will in the near future, so if there's
>> a new version of it, please let people know)
>
> At least as of 2.6.26 the old patch still works. Haven't tried with .27
> yet.
>
> -Andi
>
> --
> ak@linux.intel.com
>

Re: Fwd: [PATCH] Implement barrier support for single device DM devices

[Andi Kleen]

On Sat, Feb 14, 2009 at 12:26:05AM +0100, Mat wrote:
> Hi Andi,
> 
> any news on this patch ?

It's in mainline as of 2.6.29-rc4.

> from what I saw it isn't included in mainline yet, if it is already
> please point to the kernel-config option where to enable it

It's always enabled for simple DM remapped devices given that its conditions
(only single underlying device etc.) are true.

> heavy flush, write operations; especially on amd64/X64:
> http://forums.gentoo.org/viewtopic-t-482731.html
> 
> I'm not sure if it's possible but I believe it could also be related
> to filesystems switching to synchronous writes (non-barrier
> write-mode) when the underlying partition is a LUKS-partition and

Note that my patch doesn't enable barriers for LUKS/dm_crypt, that would
be another patch which is not currently submtted.

> therefore
> decreasing performance (I'm not a kernel-hacker so I don't know if
> there's a possible correlation here)

You can find out by testing it without LUKS, but enabling/disabling
barriers on a file system and see how much difference it makes.
That would be better than speculating.

> 
> some factors I noticed having an impact on that are:

How did you determine that? Did you run some repeatable benchmark
that gave different numbers? 

> - the i/o scheduler hardly makes a change
> - elder boxes with PCI (non-PCIe) can be "fixed" with some latency-tweaks:
>   setpci -v -d *:* latency_timer=b0

You realize that the PCI latency has nothing to do with IO scheduler
delays? It's very unlikely that there is a correlation there.
Please double check these results.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.