Messages in this thread | | | Date | Sat, 16 Nov 2002 16:11:11 -0800 | From | William Lee Irwin III <> | Subject | Re: [lart] /bin/ps output |
| |
On Sun, Nov 17, 2002 at 12:11:35AM +0000, Alan Cox wrote: > Bill - so what happens if you trim down the aio, event and ksoftirqd > threads to a sane size (you might also want to do something about the > fact 2.5 still runs ksoftirq too easily). Intuitively I'd go for a > square root of the number of processors + 1 sort of function but what do > the benchmarks say ?
Both reorganizing the per-cpu thread pools as state machines and inserting new locking look like work-intensive projects...
It's not become explosively bad yet (1MB of overhead is eyebrow-raising but not particularly damaging) so there's no rush to trim this down, but I'm at least thinking about doing this later. One of the major obstacles for the state machine approach is that the migration threads run at RT priority while the rest do not, and of course the greater than per-cpu granularity approach suffers from additional locking.
Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |