On Sun, Feb 7, 2010 at 6:11 PM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: > I think adding big chunks of sysctl code to such specific applications > is very un-unix. > > If choosing a buffer size is going to be a common operation, it should > be an API called to "ask what the buffer size should be". If that is > the case, it will soon over-commit the resources of the machine. So > then it starts being something you want a system call for. The unix > practice is to undercommit, and punish userland because userland is > commonly unefficient, while the kernel is trying to be efficient (as > much as it can). This scaling undoes that. cp will have it's > priority increased since it is "efficient", and an un-modified one > using the standard buffer sizes will be demoted. > > So I guess it begs for an extension to the UNIX system calls. > > That is a road that requires long consideration, to avoid overcommit. > You would not want a bunch of applications asking "how much should I > use", and then doing the allocation later. > > That is why I don't like what you are doing in cp. I think your > heuristic is hasty.
So how do we move forward? How do we see what works and what doesn't if we don't start somewhere? What program should I be using to test this new buffer size API? I have tried to keep the scaling conservative. If you run 2 or 10 or even more copies of the modified cp, things will be ok. It makes no assumptions about being the only program running. > For those of you who asked why cp needs to be portable, come on. > You've got it all wrong. If cp isn't written in a portable fashion, > then what is the point of doing anything else in a portable fashion. The problem with lowest common denominator is that it's always the lowest. I think we can do better.
