Re: [PATCHSET] workqueue: concurrency managed workqueue, take#4

[David Howells]

Tejun Heo <tj@xxxxxxxxxx> wrote:

> Well, you can RR queue them but in general I don't think things like
> that would be much of a problem for IO bounded works.

"RR queue"?  Do you mean realtime?

> If it becomes bad, scheduler will end up moving the source around

"The source"?  Do you mean the process that's loading the deferred work items
onto the workqueue?  Why should it get moved?  Isn't it pinned to a CPU?

> and for most common cases, those group queued works are gonna hit similar
> code paths over and over again during their short CPU burn durations so it's
> likely to be more efficient.

True.

> Are you seeing maleffects of cpu affine work scheduling during fscache load
> tests?

Hard to say.  Hear are some benchmarks:

 (*) SLOW-WORK, cold server, cold cache:

	real    2m0.974s
	user    0m0.492s
	sys     0m15.593s

 (*) SLOW-WORK, hot server, cold cache:

	real    1m31.230s	1m13.408s
	user    0m0.612s	0m0.652s
	sys     0m17.845s	0m15.641s

 (*) SLOW-WORK, hot server, warm cache:

	real    3m22.108s	3m52.557s
	user    0m0.636s	0m0.588s
	sys     0m13.317s	0m16.101s

 (*) SLOW-WORK, hot server, hot cache:

	real    1m54.331s	2m2.745s
	user    0m0.596s	0m0.608s
	sys     0m11.457s	0m12.625s

 (*) SLOW-WORK, hot server, no cache:

	real    1m1.508s	0m54.973s
	user    0m0.568s	0m0.712s
	sys     0m15.457s	0m13.969s

 (*) CMWQ, cold-ish server, cold cache:

	real    1m5.154s
	user    0m0.628s
	sys     0m14.397s

 (*) CMWQ, hot server, cold cache:

	real    1m1.240s	1m4.012s
	user    0m0.732s	0m0.576s
	sys     0m13.053s	0m14.133s

 (*) CMWQ, hot server, warm cache:

	real    3m10.949s	4m9.805s
	user    0m0.636s	0m0.648s
	sys     0m14.065s	0m13.505s

 (*) CMWQ, hot server, hot cache:

	real    1m22.511s	2m57.075s
	user    0m0.612s	0m0.604s
	sys     0m11.629s	0m12.509s

     Note that it took me several goes to get a second result for this case:
     it kept failing in a way that suggested that the non-reentrancy stuff you
     put in there failed somehow, but it's difficult to say for sure.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/