Re: [patch] dynamic buffer cache hash table size

Heinz Mauelshagen (mauelsha@ez-darmstadt.telekom.de)
Fri, 22 Jan 1999 15:18:05 MET

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Myrdraal: "Re: MEEPT!!!"
Previous message: Stephen C. Tweedie: "Re: MM deadlock [was: Re: arca-vm-8...]"
Maybe in reply to: Andrea Arcangeli: "[patch] dynamic buffer cache hash table size"

>
> On Thu, 21 Jan 1999, Andrea Arcangeli wrote:
>
> > On Thu, 21 Jan 1999, Heinz Mauelshagen wrote:
> >
> > > - buffermem is 200M of my 256M system afterwards
> > > - minimum swap.
> > > - lots of system time searching the buffer cache with
> > > commands afterwards.
> >
> > so the problem is just only the ~O(n) search in the buffer cache right?
> >
> > > - commands running 50 to 100!!! times slower than before filling buffercache
> >
> > No this is a workaround of the problem I think that right now I should
> > enlarge the buffer hash table of the buffer headers for high memory
> > machines.
>
> I've done that now. Worked fine here so far. I am allocating now 65 pages
> for my 128Mbyte RAM machine. In 64Mbyte the pages allocated for the buffer
> hash table will be 33 (continue linear...). Maybe it's too much?
>
> Could you try out if this patch against pre-8.gz (in testing) fix the `too
> much allocated buffers' problem without having to set max limit on the
> buffer cache?
>
> BTW, since I was there I also enlarged the page cache hash table from
> 8kbyte (2k entry) to 32kbyte (8k entries) since with 128Mbyte I don't care
> to lose 1 page and half to go 4 time faster (if I guess the math right)
> while browsing the cache.

Added the patch.

The bad performance nearly stays the same, when the buffermem is large 8*(
Only adding my artificial limitation for the buffermem to limit it
to for eg. 20M is almost fine.

The mke2fs of the 12G devices nearly works twice as fast (2:35 minutes
vs 4:50 minutes) and the command performance only drops from 0.4s real
to 2.3 real and not to more than 30s real.

I think that CPU cache trashing with a buffer amount of 200M might
be the big issue for my performance loss?!

Regards, Heinz

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement Entwicklungsbereich 2           Deutsche Telekom AG
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
                                                 Postfach 10 05 41
mge@ez-darmstadt.telekom.de                      64205 Darmstadt
                                                 Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement Entwicklungsbereich 2           Deutsche Telekom AG
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
                                                 Postfach 10 05 41
mge@ez-darmstadt.telekom.de                      64205 Darmstadt
                                                 Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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






 Next message: Myrdraal: "Re: MEEPT!!!"
 Previous message: Stephen C. Tweedie: "Re: MM deadlock [was: Re: arca-vm-8...]"
 Maybe in reply to: Andrea Arcangeli: "[patch] dynamic buffer cache hash table size"