lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patches in this message
    /
    From
    SubjectRE: [patch] arca-vm-19 [Re: Results: Zlatko's new vm patch] HM Patch
    Date

    Hallo Andrea!

    >
    > > On Thu, 14 Jan 1999, Fred Reimer wrote:
    >
    > > It would not be possible to implement for 2.2.0, because it's frozen except
    >
    > On Thu, 14 Jan 1999, Amdrea Agneli wrote:
    >
    > What Heinz is asking for has nothing to do with stability. I think it's
    > trivial to do what he needs without having to reinsert the buffer_max
    > limit. I think that arca-vm-20 only need an:
    >
    > echo 5 2 4 32 128 512 >/proc/sys/vm/pager
    >
    > or a:
    >
    > echo 3 2 4 32 128 512 >/proc/sys/vm/pager
    >

    Tested both but got no better performance.

    > to work well for Heinz. Heinz could you confirm that? If understand well
    > your problem is a too much heavy swapout even if there's a lot of
    > freeable buffer memory?
    >

    Correct!

    That's the cause, why i made a quick hack (not that smart for sure ;*) )
    which free's buffer memory again, limits page cache and avoids all that
    swapping (see patch below).
    If the hack makes sense to you my refill_freelist() code should
    go to linux/mm/vmscan.c and buffer_mem.max_percent should come back to
    implement a better check in grow_buffers().

    Did anybody think about correcting linux/Documentation/sysctl/vm.txt?

    > > bugs right? But, would it be possible/desireable to have different
    > > algorithms selectable as part of the kernel build process? Are their
    >
    > Sure it's possible but I think it would raise a big mess. I think it's
    > very better to have only one algorithm and have it very well tested from
    > everybody.

    I agree to Andrea's argument and vote for extension of the admin interface
    (buffer_mem.max_percent etc.)

    Heinz



    --- linux/fs/buffer.c.vm20 Fri Jan 8 00:06:59 1999
    +++ linux/fs/buffer.c Fri Jan 15 02:27:42 1999
    @@ -690,9 +690,42 @@
    static void refill_freelist(int size)
    {
    if (!grow_buffers(size)) {
    - wakeup_bdflush(1);
    - current->policy |= SCHED_YIELD;
    - schedule();
    + /* HM 14.1.99
    + test hack with necessary code parts from shrink_mmap */
    + static unsigned long clock = 0;
    + struct page * page;
    + unsigned long count = num_physpages;
    +
    + page = mem_map + clock;
    + while (count-- != 0) {
    +
    + /* This works even in the presence of PageSkip because
    + * the first two entries at the beginning of a hole will
    + * be marked, not just the first.
    + */
    + page++;
    + clock++;
    + if (clock >= max_mapnr) {
    + clock = 0;
    + page = mem_map;
    + }
    + if (PageSkip(page)) {
    + /* next_hash is overloaded for PageSkip */
    + page = page->next_hash;
    + clock = page->map_nr;
    + }
    +
    + /* We can't free pages unless there's just one user */
    + if (atomic_read(&page->count) != 1)
    + continue;
    +
    + /* Is it a buffer page? */
    + if (page->buffers) {
    + if (!try_to_free_buffers(page))
    + continue;
    + break;
    + }
    + }
    }
    }

    @@ -1402,6 +1435,13 @@
    struct buffer_head *bh, *tmp;
    struct buffer_head * insert_point;
    int isize;
    +
    + /* HM 14.1.1998
    + test hack, because somebody stole buffer_mem.max_percent ;*) */
    + if ( ( buffermem >> PAGE_SHIFT) * 100 >
    + ( pager_daemon.buffer_min_percent +
    + ( 100 - pager_daemon.buffer_min_percent) / 2) * num_physpages)
    + return 0;

    if ((size & 511) || (size > PAGE_SIZE)) {
    printk("VFS: grow_buffers: size = %d\n",size);
    --- linux/mm/vmscan.c.vm20 Thu Jan 14 17:29:15 1999
    +++ linux/mm/vmscan.c Fri Jan 15 02:23:20 1999
    @@ -472,6 +472,9 @@

    if (!shrink_mmap(priority, gfp_mask))
    grow_swap_cache = 1;
    + /* HM 14.1.99; next 2 lines (don't let it grow if we found a page) */
    + else
    + grow_swap_cache = 0;

    switch (grow_swap_cache)
    {
    --

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

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:0.034 / U:36.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site