lkml.org 
[lkml]   [2001]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: With Daniel Phillips Patch (was: aic7xxx with 2.4.9 on 7899P)


    On Tue, 21 Aug 2001, Sven Heinicke wrote:

    >
    > Forgive the sin of replying to my own message but Daniel Phillips
    > replied to a different message with a patch to somebody getting a
    > similar error to mine. Here is the result:
    >
    > Aug 20 15:10:33 ps1 kernel: cation failed (gfp=0x30/1).
    > Aug 20 15:10:33 ps1 kernel: __alloc_pages: 0-order allocation failed
    > (gfp=0x30/1).
    > Aug 20 15:10:46 ps1 last message repeated 327 times
    > Aug 20 15:10:47 ps1 kernel: cation failed (gfp=0x30/1).
    > Aug 20 15:10:47 ps1 kernel: __alloc_pages: 0-order allocation failed
    > (gfp=0x30/1).
    > Aug 20 15:10:56 ps1 last message repeated 294 times
    >
    >
    > Sven Heinicke writes:
    > >
    > > It's always a blessing and a curse when people seem to be haveing
    > > problems with the same drivers as you. I started looking into this
    > > when I user complained about disk access time. I think this is
    > > related to the running aic7xxx topics.
    > >
    > > From my tests, I got a Dell 4400 who's Adaptec 7899P, according to
    > > bonnie++, was writing slower then some of my my IDE drives on a
    > > different system. I tried Red Hat's 2.4.3-12smp kernel and got a
    > > little improvement. I then built 2.4.9 and started running bonnie++
    > > again and my syslog gets filled up with such errors:
    > >
    > > Aug 20 14:23:33 ps1 kernel: __alloc_pages: 0-order all
    > > Aug 20 14:23:36 ps1 last message repeated 376 times
    > > Aug 20 14:23:36 ps1 kernel: ed.
    > > Aug 20 14:23:36 ps1 kernel: __alloc_pages: 0-order all
    > > Aug 20 14:23:44 ps1 last message repeated 376 times
    > > Aug 20 14:23:44 ps1 kernel: ed.
    > > Aug 20 14:23:44 ps1 kernel: __alloc_pages: 0-order all
    > > Aug 20 14:23:44 ps1 last message repeated 363 times
    > >
    > > With slow access time. Please request more info if you think it might
    > > help.

    Sven,

    Could you please try the following patch on top of 2.4.9?

    diff -Nur --exclude-from=exclude linux.orig/fs/buffer.c linux/fs/buffer.c
    --- linux.orig/fs/buffer.c Wed Aug 15 18:25:49 2001
    +++ linux/fs/buffer.c Tue Aug 21 04:54:01 2001
    @@ -2447,7 +2447,8 @@
    spin_unlock(&free_list[index].lock);
    write_unlock(&hash_table_lock);
    spin_unlock(&lru_list_lock);
    - if (gfp_mask & __GFP_IO) {
    + if (gfp_mask & __GFP_IO || (gfp_mask & __GFP_NOBOUNCE)
    + && page-zone == &pgdat_list->node_zones[ZONE_HIGHMEM]) {
    sync_page_buffers(bh, gfp_mask);
    /* We waited synchronously, so we can free the buffers. */
    if (gfp_mask & __GFP_WAIT) {
    diff -Nur --exclude-from=exclude linux.orig/include/linux/mm.h linux/include/linux/mm.h
    --- linux.orig/include/linux/mm.h Wed Aug 15 18:21:11 2001
    +++ linux/include/linux/mm.h Tue Aug 21 04:52:08 2001
    @@ -538,6 +538,8 @@
    #define __GFP_HIGH 0x20 /* Should access emergency pools? */
    #define __GFP_IO 0x40 /* Can start physical IO? */
    #define __GFP_FS 0x80 /* Can call down to low-level FS? */
    +#define __GFP_NOBOUNCE 0x100 /* Don't do any IO operation which may
    + result in IO bouncing */

    #define GFP_NOIO (__GFP_HIGH | __GFP_WAIT)
    #define GFP_NOFS (__GFP_HIGH | __GFP_WAIT | __GFP_IO)
    diff -Nur --exclude-from=exclude linux.orig/include/linux/slab.h linux/include/linux/slab.h
    --- linux.orig/include/linux/slab.h Wed Aug 15 18:21:13 2001
    +++ linux/include/linux/slab.h Tue Aug 21 04:51:20 2001
    @@ -23,7 +23,7 @@
    #define SLAB_NFS GFP_NFS
    #define SLAB_DMA GFP_DMA

    -#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS)
    +#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|__GFP_NOBOUNCE)
    #define SLAB_NO_GROW 0x00001000UL /* don't grow a cache */

    /* flags to pass to kmem_cache_create().
    diff -Nur --exclude-from=exclude linux.orig/mm/highmem.c linux/mm/highmem.c
    --- linux.orig/mm/highmem.c Thu Aug 16 13:42:45 2001
    +++ linux/mm/highmem.c Tue Aug 21 04:50:08 2001
    @@ -321,7 +321,7 @@
    struct page *page;

    repeat_alloc:
    - page = alloc_page(GFP_NOIO);
    + page = alloc_page(GFP_NOIO|__GFP_NOBOUNCE);
    if (page)
    return page;
    /*
    @@ -359,7 +359,7 @@
    struct buffer_head *bh;

    repeat_alloc:
    - bh = kmem_cache_alloc(bh_cachep, SLAB_NOIO);
    + bh = kmem_cache_alloc(bh_cachep, SLAB_NOIO|__GFP_NOBOUNCE);
    if (bh)
    return bh;
    /*
    diff -Nur --exclude-from=exclude linux.orig/mm/page_alloc.c linux/mm/page_alloc.c
    --- linux.orig/mm/page_alloc.c Thu Aug 16 13:43:02 2001
    +++ linux/mm/page_alloc.c Tue Aug 21 04:51:03 2001
    @@ -398,7 +398,8 @@
    * - we're /really/ tight on memory
    * --> try to free pages ourselves with page_launder
    */
    - if (!(current->flags & PF_MEMALLOC)) {
    + if (!(current->flags & PF_MEMALLOC)
    + || ((gfp_mask & __GFP_NOBOUNCE) && !order)) {
    /*
    * Are we dealing with a higher order allocation?
    *
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:57    [W:0.031 / U:60.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site