Date: Sun, 2 Nov 1997 12:39:43 -0800 (PST) From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> To: Tom <tom@sdf.com> Cc: Wolfram Schneider <wosch@cs.tu-berlin.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: Suggested addition to /etc/security Message-ID: <Pine.BSF.3.96.971102123256.458A-100000@trojanhorse.ml.org> In-Reply-To: <Pine.BSF.3.95q.971102113620.17102A-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've thought about this before, it would be interesting to be able to limit the rate of i/o per second for a process. Since find isn't really eating much user cpu, it is all that time spent in the kernel thrashing the disk that makes the difference. Maybye even better you could limit the _physical i/o_, this is really the same reason any user can seriously lag the system with a: cat /dev/urandom > /dev/null This is really a flaw in the prioritization design that only CPU is considered and not i/o (unless I am mistaken, which is emminently possible) > find is perhaps disk i/o bound, depeding on the speed of the disks and > cpu. I notice here that doing just a "find . > /dev/null" rachets up the > load quite nicely. More complex find options will hurt even more. > > Also, chewing up disk i/o bandwidth isn't a good thing either, will hurt > other applications. > > Is it possible to run /etc/security and not have performance degraded > during this period? It seems that either the CPU and/or disk bandwith > will takes a big hit. > > > Root-Cron jobs should never started with idprio because a non-root > > user process can block the jobs. This is a security risk ;-) > > > > -- > > Wolfram Schneider <wosch@apfel.de> http://www.apfel.de/~wosch/ > > > > > > Tom > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971102123256.458A-100000>