[lkml]   [2001]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: 2.4.6 and ext3-2.4-0.9.1-246
    My system is:
    Dual 1Ghz PIII
    2G RAM
    2x2G swapfiles
    And I ran tiobench as --size 4000 (twice memory)

    Me thinkst SMP is probably the biggest difference in this list.

    I ran this on another "smaller" memory (still dual CPU though) machine and
    noticed this on top:

    12983 root 15 0 548 544 448 D 73.6 0.2 0:11 tiotest
    3 root 18 0 0 0 0 SW 72.6 0.0 0:52 kswapd

    kswapd is taking an awful lot of CPU time. Not sure why it should be
    hitting swap at all.
    I noticed a similar behavior even with NO swap -- kswapd still chewing up

    Michael D. Black Principal Engineer 321-676-2923,x203 Computer Science Innovations My home page
    FAX 321-676-2355
    ----- Original Message -----
    From: "Andrew Morton" <>
    To: "Mike Black" <>
    Cc: "linux-kernel@vger.kernel.or" <>;
    Sent: Wednesday, July 11, 2001 12:08 AM
    Subject: Re: 2.4.6 and ext3-2.4-0.9.1-246

    Mike Black wrote:
    > I started testing 2.4.6 with ext3-2.4-0.9.1-246 yesterday morning and
    > immediately hit a wall.
    > Testing on a an SMP kernel -- dual IDE RAID1 set the system temporarily
    > locked up (telnet window stops until disk I/O is complete).

    Mike, we're going to need a lot more detail to reproduce this.

    Let me describe how I didn't reproduce it and perhaps
    you can point out any differences:

    - Kernel 2.4.6+ext3-2.4-0.9.1.

    - Two 4gig IDE partitions on separate disks combined into a
    RADI1 device.

    - 64 megs of memory (32meg lowmem, 32meg highmem)

    - 1 gig swapfile on the ext3 raid device.

    - Ran ./ --threads 16

    That's a *lot* more aggressive than your setup, yet
    it ran to completion quite happily.

    I'd be particularly interested in knowing how much memory
    you're using. It certainly sounds like you're experiencing
    memory exhaustion. ext3's ability to recover from out-of-memory
    situations was weakened recently so as to reduce our impact
    on core kernel code. I'll be generating an incremental patch
    which puts that code back in.

    In the meantime, could you please retest with this somewhat lame

    --- linux-2.4.6/mm/vmscan.c Wed Jul 4 18:21:32 2001
    +++ lk-ext3/mm/vmscan.c Wed Jul 11 14:03:10 2001
    @@ -852,6 +870,9 @@ static int do_try_to_free_pages(unsigned
    * list, so this is a relatively cheap operation.
    if (free_shortage()) {
    + extern void shrink_journal_memory(void);
    + shrink_journal_memory();
    ret += page_launder(gfp_mask, user);
    shrink_dcache_memory(DEF_PRIORITY, gfp_mask);
    shrink_icache_memory(DEF_PRIORITY, gfp_mask);
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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