[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] a question about popen() performance on domU
> > Because it's using the same source for glibc! glibc says to use
> > _IO_fork(), which is calling the fork syscall. Clone would
> probably do
> > the same thing, but for whatever good or bad reason, the
> author(s) of
> > thise code chose to use fork. There may be good reasons, or
> no reason
> > at all to do it this way. I couldn't say. I don't think it makes a
> > whole lot of difference if the actual command executed by popen is
> > actually "doing something", rather than just an empty "return".
> I am not very sure about your comment in the last sentence.
> Are you suggesting the command passed to popen should have no
> big effect on popen's performance?
No, my point was that clone and fork are very similar, and if you
ACTUALLY do something in the forked/cloned process, the difference
betweent the two process creating mechanisms would be very similar -
however, if you don't do anything inside the popen, you get to see the
difference. The thing is that popen is meant to spawn a process that
actually does something - at least that's the general idea. That is why
this sort of microbenchmark that tests a paricular system call is often
quite useless - if you where to spawn of a gcc compile, do you think the
time taken to actually perform popen would be noticable, compared to the
compiling of some kilobytes of source-code [if you use -pipe on gcc I
believe it would use popen to create the next level compile]?
Application benchmarks are much more meaningfull for the end users and
with the right tools can be used to direct the kernel developers to look
at the right areas of the kernel to increase the performance of the
system - which is probably not going to be suboptimisations inside
Xen-devel mailing list