Whenever I find myself wishing for such knobs, I simply install FreeBSD.

2010/2/6 Vadim Zhukov <persg...@gmail.com>:
> On 6 February 2010 c. 17:53:09 Otto Moerbeek wrote:
>> On Sat, Feb 06, 2010 at 09:14:53AM -0500, Ted Unangst wrote:
>> > On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis
> <mark.kette...@xs4all.nl> wrote:
>> > >> > Continuing in my "make IO suck less" phase, cp would be a lot
>> > >> > more efficient if it didn't bounce the disk heads around so
>> > >> > much. ?Instead of using a tiny 64k buffer, use an amount based
>> > >> > on a small fraction of RAM.
>> > >>
>> > >> Isn't it the task of the buffer cache to optimize memory use
>> > >> here?
>> > >
>> > > Exactly the point I was just about to raise.
>> >
>> > Optimizing memory has nothing to do with it.  The buffer cache
>> > doesn't do a whole lot to reduce seeking.  This is what cp looks
>> > like:
>> >
>> > read .000001s
>> > seek .001s
>> > write .000001s
>> > seek .001s
>> > read .000001s
>> > seek .001s
>> >
>> > It doesn't matter if the buffer cache does readahead, it never reads
>> > enough ahead.  It doesn't matter if the buffer cache is write back,
>> > the writes are still in the queue, and the elevator still goes.  If
>> > you were moving from the 10th floor to the 90th floor, would you
>> > take the boxes up one at a time?
>>
>> The buffer cache should ne smart enough to optmize read and writes in
>> such large chunks so that the seeking gets reduced. The problem with
>> your big buffers is that you are claiming resources even if you have
>> no idea if they are available or not.
>>
>>       -Otto
>
> I have a cool idea about super-duper-mega-knob.
>
> Let's choose and use globally a new environment variable, say,
> LIVEFASTDIEYOUNG. If it's not defined, or empty, then current, sane
> defaults will be used in programs; otherwise, programs should go
> searching the shortest way to strike yourself in the foot.
>
> Then each program you want can be modified to depend on it:
>
>    const char *lfdy = getenv("LIVEFASTDIEYOUNG");
>    if (lfdy != NULL && *lfdy != '\0') {
>        // Do some crazy things
>    } else {
>        // Sane as usual
>    }
>
> Or this could be an sysctl, so even kernel flow can be modified. Yes,
> it'll produce more bloat, but who cares? ;)
>
> --
>  Best wishes,
>    Vadim Zhukov
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
> P.S.: Didn't want to hurt anyone. Really.

Reply via email to