Re: CVS commit: src/usr.bin/pathchk
On Wed, 10 Nov 2010, Christoph Badura wrote:
On Tue, Nov 09, 2010 at 08:34:56PM +, Alan Barrett wrote:
Modified Files:
src/usr.bin/pathchk: pathchk.1
Log Message:
Change the ironically unafe find . -print | xargs pathchk -p to
the safe find . -exec pathchk -p \{\} + in an example.
Why not save all the forks and use find . -print0 | xargs -0 pathchk -p?
The reason I didn't use -print0 or xargs -0 is that both those
features are extensions to POSIX, whereas -exec ... + in standardised.
-exec ... + and xargs will both accumulate many args into each
invocation of the child program, and will both fork the same number of
times. The version using xargs is actually less efficient, because
there's one extra fork to run xargs itself, and there's extra I/O over
the pipeline.
Christos seems to have made the same mistake as you, confusing -exec
... \; (which runs a separate child program for each file name) with
-exec ... + (which passes many file names to each invocation of the
child program).
--apb (Alan Barrett)
Re: CVS commit: src/usr.bin/pathchk
In article 20101110113444.ge...@apb-laptoy.apb.alt.za,
Alan Barrett a...@cequrux.com wrote:
On Wed, 10 Nov 2010, Christoph Badura wrote:
On Tue, Nov 09, 2010 at 08:34:56PM +, Alan Barrett wrote:
Modified Files:
src/usr.bin/pathchk: pathchk.1
Log Message:
Change the ironically unafe find . -print | xargs pathchk -p to
the safe find . -exec pathchk -p \{\} + in an example.
Why not save all the forks and use find . -print0 | xargs -0 pathchk -p?
The reason I didn't use -print0 or xargs -0 is that both those
features are extensions to POSIX, whereas -exec ... + in standardised.
-exec ... + and xargs will both accumulate many args into each
invocation of the child program, and will both fork the same number of
times. The version using xargs is actually less efficient, because
there's one extra fork to run xargs itself, and there's extra I/O over
the pipeline.
Christos seems to have made the same mistake as you, confusing -exec
... \; (which runs a separate child program for each file name) with
-exec ... + (which passes many file names to each invocation of the
child program).
Yes, I did not know about exec {} +
christos
Re: CVS commit: src/sys/kern
On Tue, Nov 09, 2010 at 12:36:16PM +0900, Masao Uebayashi wrote: The root cause of such a problem is, we don't do I/O scheduling at all. I think that pool(9) (and pool_cache(9)) is a great tool to manage limited resources. The way to go would be to extend it to manage bandwidth in I/O subsystems. (We already use pool_cache(9) for KVA.) Resources are shared, and have dependencies. I/O resources would look like some hierachical structure chained with pool backend callbacks. Probably combined with device tree too. FWIW, I'm working on managing PCI I/O resources in this way, but I'm probably going to use vmem(9), not pool(9). Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/sys/kern
On Wed, Nov 10, 2010 at 10:27:50AM -0600, David Young wrote: On Tue, Nov 09, 2010 at 12:36:16PM +0900, Masao Uebayashi wrote: The root cause of such a problem is, we don't do I/O scheduling at all. I think that pool(9) (and pool_cache(9)) is a great tool to manage limited resources. The way to go would be to extend it to manage bandwidth in I/O subsystems. (We already use pool_cache(9) for KVA.) Resources are shared, and have dependencies. I/O resources would look like some hierachical structure chained with pool backend callbacks. Probably combined with device tree too. FWIW, I'm working on managing PCI I/O resources in this way, but I'm probably going to use vmem(9), not pool(9). That is PCI I/O *space*, right? I agree vmem(9) is suitable for that. What I meant is I/O descriptors like mbuf or struct buf. Something like altq generalized for I/O queues. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933 -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/usr.bin/pathchk
On Wed, Nov 10, 2010 at 01:34:02PM +, Christos Zoulas wrote:
Christos seems to have made the same mistake as you, confusing -exec
... \; (which runs a separate child program for each file name) with
-exec ... + (which passes many file names to each invocation of the
child program).
Yes, I did not know about exec {} +
Neither did I; when was it invented? Did the POSIX folks come up with
something good for a change?
--
David A. Holland
dholl...@netbsd.org
Re: CVS commit: src/usr.bin/pathchk
On Wed, Nov 10, 2010 at 06:19:25PM +, David Holland wrote:
On Wed, Nov 10, 2010 at 01:34:02PM +, Christos Zoulas wrote:
Christos seems to have made the same mistake as you, confusing -exec
... \; (which runs a separate child program for each file name) with
-exec ... + (which passes many file names to each invocation of the
child program).
Yes, I did not know about exec {} +
Neither did I; when was it invented? Did the POSIX folks come up with
something good for a change?
Ditto - which probably means it is less portable that -print0 :-)
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/usr.bin/pathchk
On Wed, 10 Nov 2010, David Holland wrote:
Yes, I did not know about exec {} +
Neither did I; when was it invented? Did the POSIX folks come up with
something good for a change?
I don't know when it was invented, but it's in The Open Group Base
Specifications Issue 6, a.k.a. IEEE Std 1003.1, 2004 edition. It's
even in Solaris.
--apb (Alan Barrett)
