> not being optimised, and it used up to 230M of memory whereas I have 128M
> of physical ram. Of course, it swapped a lot, as I expected it. But ...
> the system was absolutely unusable during that time. Not just slow ...
> absolutely unusable.
Sure, the process was swapping out from fast memory to a slow disk...
as far as it being unusable, the kernel was probably busy juggling
interrupts. This is probably a question for an x86 person who is
familiar with the new generation of eide disks; all of my boxes are
axp with scsi.
> Now I *hear* (but is it true?) that *BSD handles this sort of case much
> more nicely. Is it true? Is there anything planned to make linux perform
Possibly. I've used Linux for 7 years, dropped code into the
main kernel and am actively working on a distribution, but went with
FreeBSD on the desktop at work. Tried an equally-configured Linux box,
but it would repeatedly choke and panic when loading large (.5-2G)
tcpdump captures. Best thing you can do in this situation is
back off your data, stick BSD on the hardware, and compare results.
In the 'real world' (whatever that is), application performance usually
determines platform choice.
That said, a personal Linux dev box (500Mhz EV56 w/768M ram,
UW-SCSI disk array) chews up said large captures for breakfast
without flinching or crashing.
> better in this area? Are there workarounds? Niceing the process doesn't
> seem to do any good. Is there, for example, a way to force a process not
> to consume more than a certain % of the CPU?
Shell ulimits (bash(1)) are the current way of handling this.
It would be nice to get a set of userland tools for setting
processor affinity, per-pid/uid resource tweaking, etc.
-- Dan Frasnelli Security analyst- 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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:14 EST