Re: [Patch] statistics infrastructure - update 9

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

 



Andi Kleen wrote:
Good question. Btw. - faster by what order of magnitude?

pushf + popf is on K8 at least ~18 cycles, on P4 it is much more
because they synchronize the pipeline there (hundreds of cycles)

cpu local add would be a few cycles at best and doesn't have
any impact on the pipeline


local_irq_save/restore seems to be fine for kernel/profile.c


Reason 1:
cpu_local_* uses __get_cpu_var, which conflicts with struct statistic
being embedded into struct xyz that is allocated whenever the client
needs it.

I could try to use local_t in conjunction with local_add etc.
(as seen in include/linux/dmaengine.h in 2.6.17-mm6).
Does this also yield a performance gain worth consideration?

Yes, but you would need preempt_disable() then. For non preemptible
kernels (far majority) that would be already a big win.


So, removing local_irq_save/restore would require statistics to be
switched on and their buffers being available all the time. That is,
buffers holding counters etc. can't be allocated at run time - what
if allocation fails? (Should I leave this issue to clients?).

Can't you use RCU for this?


Reason 4:
The alleged overhead of local_irq_save/restore (as compared
to atomic operations)

local_* doesn't need to be atomic. IT isn't on x86 at least.
On some other architectures it can be, but i think it's just a SMOP
of fixing them.

-Andi

Thanks. I am seriously considering these techniques.

If I manage to use RCU for most of the read-mostly struct statistic
and to push any other locking issues down into individual statistic
disciplines (utilisation indicator, histogram and so on), I should be
able to use local_t for some disciplines (particularyl counter and
histogram) without needing other locking primitives, like
local_irq_save/restore currently currently found in the code.

Not a change that can be done this afternoon, though.
And it will require careful review.

Martin

-
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