From owner-freebsd-hackers Sun Nov 2 12:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11153 for hackers-outgoing; Sun, 2 Nov 1997 12:40:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11147 for ; Sun, 2 Nov 1997 12:40:06 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id MAA00481; Sun, 2 Nov 1997 12:39:43 -0800 (PST) Date: Sun, 2 Nov 1997 12:39:43 -0800 (PST) From: "Jamil J. Weatherbee" To: Tom cc: Wolfram Schneider , freebsd-hackers@FreeBSD.ORG Subject: Re: Suggested addition to /etc/security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 http://www.apfel.de/~wosch/ > > > > > > Tom > >