On 14/01/2008, Alexander Schrijver <[EMAIL PROTECTED]> wrote: > On Jan 14, 2008 2:34 PM, Andreas Kahari <[EMAIL PROTECTED]> wrote: > > > > On 14/01/2008, Alexander Schrijver <[EMAIL PROTECTED]> wrote: > > > On Jan 14, 2008 1:30 PM, Andreas Kahari <[EMAIL PROTECTED]> wrote: > > > > On 14/01/2008, Alexander Schrijver <[EMAIL PROTECTED]> wrote: > > > > > On Jan 14, 2008 11:52 AM, Andreas Kahari <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > > > > > > > Is there a way of limiting the amount of CPU given to a particular > > > > > > process or process group? For example, I would want the build of the > > > > > > qt4 port to use a maximum of 25% of the available CPU, leaving the > > > > > > CPU > > > > > > 75% idle if nothing else is happening on the machine. > > > > > > > > > > > > I know about 'nice', but it doesn't fulfil the criteria that the > > > > > > machine is left otherwise idle if nothing else runs on it. > > > > > > > > > > > > I don't have a real reason for why I would want to do this, I'm > > > > > > mainly > > > > > > curious as to if it's possible. > > > > [cut] > > > > > > > > > > I have never done this myself, but I believe this is possible by > > > > > creating a login class in /etc/login.conf and set the cputime option. > > > > > See login.conf(5) for a better description. > > > > > > > > Hi Alexander, > > > > > > > > I believe that the cputime resource limit will limit the maximum > > > > amount of CPU time that the user may use in a session, which is not > > > > really what I asked for. I'd like the process or process group to run > > > > for as long as it needs to run, but that it only ever uses a fraction > > > > of the CPU power. > > > > > > > > It's like limiting the network bandwidth for a particular type of > > > > traffic, only this is about time on the CPU. [cut sigs] > > > > > > Yes, you are right. It is also possible to set a priority for a > > > process in a login class. > > > > > > From login.conf(5) > > > priority number Initial priority (nice) > > > level. > > > > > > This is not exactly what you want, but it is pretty close. I am > > > curious why do you want to set an exact limit and not let the > > > scheduler do this for you? > > > > > > > As I said, I don't have a good reason for wanting to do this. It just > > seemed like something someone might want to do. But let me dream up > > three examples: Sometimes firefox (or whatever program) goes a bit > > haywire and brings the machine to a crawl. It would be nice to limit > > firefox's CPU to a maximum of, say, 50% so that I'm guaranteed to have > > 50% of the machine to work with. > > > > Another example: Let's say I'm rebuilding the kernel, base system, and > > all my packages after a major update from CVS after a long time away. > > I'm not worried about how long this takes so I'm quite happy to run > > the build at 5% of the CPU while I get on with my work. > > > > What you describe here is exactly what you can accomplish with either > nice or the priority option in login.conf. Also, I am not exactly sure > what you mean with percent of CPU. Do you mean the difference of cpu > time scheduled between a 'normal' process?
It is not quite the same because a process, even running at niceness level 20, will grab as much CPU as it can (unless it has to wait for data). What I mean is what I wrote in my first email: "For example, I would want the build of the qt4 port to use a maximum of 25% of the available CPU, leaving the CPU 75% idle if nothing else is happening on the machine." > > Third example, similar to the last one: I'm running a distributed.net > > or SETI-at-home client in the background, but I don't ever want it to > > run at 100% of the CPU, maybe because that would make the machine too > > noisy during the night (due to the fans). > > I think this is a different issue. I don't know how this can be > solved. An idea might be to underclock your cpu at night. Yes, I could "sysctl -w hw.setperf=0" or something like that on my SpeedStep'able CPU, but with hw.setperf=0, a process still have the possibility to get 100% of the CPU. It will be a slower CPU, but it's still not limiting the process to use only a fraction of the CPU at any instance in time. Again, maybe no-one has these kind of requirements in real life? Regards, Andreas -- Andreas Kahari Somewhere in the general Cambridge area, UK
