Re: vmstat: On demand vmstat workers V4

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

 



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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]