[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080409181010.GA4924@martell.zuzino.mipt.ru>
Date: Wed, 9 Apr 2008 22:10:10 +0400
From: Alexey Dobriyan <adobriyan@...il.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Jason Baron <jbaron@...hat.com>, Adrian Bunk <bunk@...sta.de>,
Christoph Hellwig <hch@...radead.org>, akpm@...l.org
Subject: Re: [patch 09/17] Add all cpus option to stop machine run
Please, stop Cc'ing me on this.
I continue to think that all this so-called "immediate" infrastructure
is an absolute overkill and declared D-cache line savings will _never_
matter and will never be measured on real life workloads. Right now you
claim 1 (one) cacheline saving in schedule() which can be trivially
moved under CONFIG_PROFILING umbrella. On the other hand is more ugly
assembler code. Sorry, people add infra with much better good/bad ratios.
Also, my gut feeling of a guy who is also on receiveing end of bugreports
at SWsoft that line with .text games was crossed by SMP alternatives and
fooprobes. The rest won't matter because programs like firefox will fuck
up L1, L2 caches in one blow just by showing animation.
We don't need bugs when immediate update screwed up fighting for
cacheline.
And bugs when screwup happened out of the window of "Code:" printout, so
you won't have a chance to compare relevant vmlinux .text and printout.
And bugs when CPU executed bullshit and silently rebooted.
And so on.
Alexey, more and more liking OpenBSD
where such games won't even
hit mailing lists
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists