lkml.org 
[lkml]   [1999]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux Tuning
Date
> There was some talk about system call accounting last week.  The cleanest
> place to add this is in assembly code which I'm not qualified to modify.
> (I don't find the number of system calls a particularly interesting number,
> but it should be there for correlation purposes.)

You can get this for a given process by running strace -c. I'm not
sure if there is much to be gained from putting it in the kernel.

There *is* some interesting stuff to be added to the kernel for
performance monitoring, but I would parallel the tuning
discussion. Two examples:

1) Resource exhaustion. If you get more than 300 packets in 1/100 of a
second, you overflow the backlog queue. You can raise this by messing
with /proc/sys/net/core/netdev_max_backlog, but how would you know to
do this? One answer is to have the kernel print warnings when the
queue fills and packets are dropped. These warnings should not appear
too often, i.e. once every 20 minutes along with the # of packets
dropped. The *bsd's are pretty good with this kind of thing.

2) Resource monitoring. It looks to me like the way to tune bdflush
(/proc/sys/vm/bdflush) is to monitor how many pages/sec are consumed
etc etc. If the system is constantly running low, then you may want to
fiddle with the pages cleaned per action. This requires more
monitoring than is currently present.

-- g

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.049 / U:14.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site