Date: Thu, 8 Jul 2004 15:50:15 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Dag-Erling Sm?rgrav <des@des.no> Cc: current@freebsd.org Subject: Re: RFC: Sorting in top -m io Message-ID: <20040708225015.GR95729@elvis.mu.org> In-Reply-To: <xzpwu1e3zpb.fsf@dwp.des.no> References: <20040707124751.GA66588@orion.daedalusnetworks.priv> <xzpwu1e3zpb.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
* Dag-Erling Sm?rgrav <des@des.no> [040708 15:24] wrote: > Giorgos Keramidas <keramida@freebsd.org> writes: > > What do you all think of this patch to top(1)? > > extremely inefficient; get_io_stats() is an expensive function and you > really don't want to call it approximately log(n) per process while > sorting, especially when it returns the same values every time. > > an ugly trick to get around this is to have get_process_info() store > io stats in ki_spare[] or some other unused kinfo_proc field, so you > never need to call get_io_stats() outside get_process_info(). I think you could generate an array indexed by the offset into the procs feild... If that's not clear I may be able to whip up a cache of that info tonight for you. (instead of spamming a feild in the array.) > you should also do secondary sort orders like the existing compare_*() > functions do, since qsort() is unstable, so processes with identical > stats will jump around if they aren't also sorted by name or some > other secondary criterion. You can use mergesort, but I may be missing the point. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040708225015.GR95729>