Is this statistically significant?
Looks like the I/O scheduler has slipped a bit. Nick did some testing which
shows that read-latency2 is still outperforming 2.5 by a factor of twenty on
read-vs-write fairness. He's working on that, but there is still a lot to do
on this front. We are nowhere near good enough yet.
> A full set of archived results and hardware specs can be found here:
> http://www.osdl.org/projects/ctdevel/results/
>
> This is a good time to repeat the bug report that looked like spam last time I
> posted it (sorry my mailer seemed to bork):
>
> Since moving contest to c I get an error trying to fork with all 2.5 kernels I
> try after running it on the 6th load. The error does not occur with any 2.4
> kernels. I have confirmed it is still present on 2.5.58.
>
> To reproduce the problem:
> Run the latest version of contest without arguments (0.61pre) and after
> no_load,cacherun,process_load,ctar_load,xtar_load and io_load it bombs out
> with:
> bmark.c:43: SYSTEM ERROR: Cannot allocate memory : fork error
>
> It seems to occur only after a few loads followed by io_load.
>
Ho hum. "it works for me".
My guess would be that ext3 has confused vm_enough_memory(). See, if you
delete an ext3 file immediately after writing it (as io_load does), ext3 will
leave all the pages on the page LRU, with attached buffers.
These pages are trivially reclaimable, but as far as the VM accounting is
concerned these pages are nowhere to be seen. So vm_enough_memory() says
"nope, not enough memory to fork". Perhaps.
Could you please do
echo 1 > /proc/sys/vm/overcommit_memory
and see if it goes away?
I don't know what to do about this yet. Probably need to try to release
those buffers in ext3.
-
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/