lkml.org 
[lkml]   [2000]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Updated 2.4 TODO List
    On Mon, 9 Oct 2000 tytso@mit.edu wrote:

    > 2. Capable Of Corrupting Your FS/data
    >
    > * Non-atomic page-map operations can cause loss of dirty bit on
    > pages (sct, alan)

    Is anybody looking into fixing this bug ?

    > 9. To Do
    >
    > * mm->rss is modified in some places without holding the
    > page_table_lock (sct)

    Probably not a show-stopper, but we're looking for
    volunteers to fix this one anyway ;)

    > * VM: Out of Memory handling {CRITICAL}

    Seems to work now, except for the fact that it is possible
    to end up with a heavily thrashing system that /just/ didn't
    run out of memory and doesn't get anything killed.

    Then again, you can end up with a heavily thrashing system
    where you can't get anything done without running out of swap
    anyway ... the proper fix for this is probably some form of
    thrashing control...

    > * VM: Fix the highmem deadlock, where the swapper cannot create low
    > memory bounce buffers OR swap out low memory because it has
    > consumed all resources {CRITICAL} (old bug, already reported in
    > 2.4.0test6)

    Haven't been able to reproduce it on my 1GB test machine,
    but it might still be there. Can anyone confirm if this
    bug is still present ?

    > * VM: page->mapping->flush() callback in page_lauder() for easier
    > integration with journaling filesystem and maybe the network
    > filesystems

    Possibly a 2.5 issue, or something to merge later in 2.4,
    since we don't have journaling filesystems in the kernel
    anyway. I guess we'll want it for the network filesystems
    though.

    But this is a fairly simple thing to integrate:
    1) have an appropriate function in the filesystems
    2) insert function pointer in the right struct
    3) call the function from vmscan.c::page_launder()

    > * VM: maybe rebalance the swapper a bit... we do page aging now so
    > maybe refill_inactive_scan() / shm_swap() and swap_out() need to
    > be rebalanced a bit

    I'll try to look into this (3 days to go before I have to
    leave for Miami) and see how things can be improved here.

    > 11. To Check
    >
    > * VFS?VM - mmap/write deadlock (demo code seems to show lock is
    > there)

    Does anyone have the demo code at hand so we can verify if this
    still happens ?

    > * Stressing the VM (IOPS SPEC SFS) with HIGHMEM turned on can hang
    > system (linux-2.4.0test5, Ying Chen, Rik van Riel)

    Ditto. Can this still be reproduced with the latest VM or was
    it simply a side effect of something else in the VM that got
    fixed recently ?

    (the highmem code itself looks ok so the bug might well have
    been caused by a side effect of something else)

    > 12. Probably Post 2.4
    >
    > * addres_space needs a VM pressure/flush callback (Ingo)

    [duplicate item?]

    We may want this to better support the journaling filesystems
    in 2.4 .... but I agree that it should probably be post 2.4.0.

    > * VM: physical->virtual reverse mapping, so we can do much better
    > page aging with less CPU usage spikes
    > * VM: better IO clustering for swap (and filesystem) IO
    > * VM: move all the global VM variables, lists, etc. into the pgdat
    > struct for better NUMA scalability
    > * VM: (maybe) some QoS things, as far as they are major improvements
    > with minor intrusion

    These 4 seem /definate/ 2.5 issues, though I hope to have them
    (except maybe QoS?) ready in an patch before 2.5.0 is split off.

    > * VM: thrashing control, maybe process suspension with some forced
    > swapping ?
    > * VM: include Ben LaHaise's code, which moves readahead to the VMA
    > level, this way we can do streaming swap IO, complete with
    > drop_behind()

    These two are fairly simple and may well be done in the next
    few weeks. If no bug reports about the current 2.4 VM pop up,
    I'll probably look into some of the issues above...


    FYI, my personal VM TODO list:
    - see if refill_inactive_scan(), swapout_shm(), swap_out(), etc...
    need rebalancing
    - anti-thrashing code (if no hidden nasties are present)
    - better IO clustering + readahead at VMA level

    AFAIK Juan Quintela is already looking into the ->flush()
    callback for journaling filesystems.

    And one more TODO item:

    * pinned page reservation system for journaling filesystems


    regards,

    Rik
    --
    "What you're running that piece of shit Gnome?!?!"
    -- Miguel de Icaza, UKUUG 2000

    http://www.conectiva.com/ http://www.surriel.com/

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

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