[procps] Re: cgroup support for new top
- From: "Dr. Werner Fink" <werner@xxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 13 Apr 2011 15:13:13 +0200
On Fri, Apr 08, 2011 at 10:44:03AM -0500, Jim Warner wrote:
>
> On Apr 7, 2011, at 4:46 AM, Jan Görig wrote:
> ...
> > Jim, could you review this patch, please? Thanks.
> >
>
> Hi Jan,
>
> I never imagined there would be need for a 2nd variable width column. Your
> approach in sharing maxcmdln made sense but there was a problem with the
> altered endpflg scrolling logic. Also, I have this character flaw wherein I
> hate to proliferate loops.
>
> In addressing those issues I decided to go whole hog and update some
> identifiers and comments. The attached patch is offered as an alternative
> against a clean newtop.
>
> When the libproc cgroup interface has been optimized and finalized, I'd be
> happy to clean up top.
>
> By the way, Craig is sitting on some patches to newtop and I've got one more
> set in the pipeline. I'm trying to build a fire under our Sydney associate.
>
> Regards,
> Jim
Hmmm ... just test top of the current git repository and
I'm missing a lot of things like:
* Support for extrem huge systems with a lot of cpus
that is memory with more than 10 or 100 or 1000 gig
beside this the format is to small for the numbers
of cpus (%2u should be %3u)
* There is no batch support (in batch mode please no
handler for SIGHUP)
* There seems to be no hotplug support for cpus
* There is no support for oom_score and oom_adjustment
* top does crash in small terminals:
*** glibc detected *** ./top: malloc(): memory corruption: 0x0805b7e0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7697654]
/lib/libc.so.6[0xb7699c8a]
/lib/libc.so.6(__libc_malloc+0x9c)[0xb769b88c]
/lib/libc.so.6(qsort_r+0x7c)[0xb7657dbc]
/lib/libc.so.6(qsort+0x2e)[0xb765806e]
./top[0x804c6f4]
* top does crash in case of a exterm large winname
all those change I've submitted in my clone of the git repository.
Please consider to add those changes.
OK most of our openSUSE users will not be hurt by those changes
but for the SuSE Linux Enterprise servers those changes are
indispensable ... think on a system with let's say 500 cpus and
for each cpu 2gigs of ram (that is not a joke as I've a bug
report for such type of systems) and a running top running within
screen which it selfs runs in an xterm to monitor such a system
over a serial line, and now press 1 to toggle smp view ;)
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
Other related posts:
