linux-kernel - Re: vmstat: On demand vmstat workers V4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 May 2014 00:57:15 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Christoph Lameter <cl@...ux.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Tejun Heo <tj@...nel.org>, Mike Frysinger <vapier@...too.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	hughd@...gle.com, viresh.kumar@...aro.org,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: vmstat: On demand vmstat workers V4

On Fri, 9 May 2014, Christoph Lameter wrote:
> On Fri, 9 May 2014, Thomas Gleixner wrote:
> > I understand why you want to get this done by a housekeeper, I just
> > did not understand why we need this whole move it around business is
> > required.
> 
> This came about because of another objection against having it simply
> fixed to a processor. After all that processor may be disabled etc etc.

I really regret that I did not pay more attention (though my cycle
constraints simply do not allow it).

This is the typical overengineering failure: 

  Before we even have a working proof that we can solve the massive
  complex basic problem with the price of a dedicated housekeeper, we
  try to make the housekeeper itself a moving target with the price of
  making the problem exponential(unknown) instead of simply unknown.

I really cannot figure out why a moving housekeeper would be a
brilliant idea at all, but I'm sure there is some magic use case in
some other disjunct universe.

Whoever complained and came up with the NOT SO brilliant idea to make
the housekeeper a moving target, come please forth and explain:

- How this can be done without having a working solution with a
  dedicated housekeeper in the first place

- How this can be done without knowing what implication it has w/o
  seing the complexity of a dedicated housekeeper upfront.

Keep it simple has always been and still is the best engineering
principle.

We all know that we can do large scale overhauls in a very controlled
way if the need arises. But going for the most complex solution while
not knowing whether the least complex solution is feasible at all is
outright stupid or beyond.

Unless someone comes up with a reasonable explantion for all of this I
put a general NAK on patches which are directed to kernel/time/*

Correction:

I'm taking patches right away which undo any damage which has been
applied w/o me noticing because I trusted the responsible developers /
maintainers.

Preferrably those patches arrive before my return from LinuxCon Japan.

Thanks,

	tglx
--
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/