[lkml]   [2009]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: upcoming item: get_page_from_freelist
    On Wed, Jun 24, 2009 at 03:07:14PM -0700, Andrew Morton wrote:
    > fs/jbd/journal.c: new_bh = alloc_buffer_head(GFP_NOFS|__GFP_NOFAIL);
    > But that isn't :(

    Well, we could recode it to do what journal_alloc_head() does, which
    is call the allocator in a loop:

    ret = kmem_cache_alloc(journal_head_cache, GFP_NOFS);
    if (ret == NULL) {
    jbd_debug(1, "out of memory for journal_head\n");
    if (time_after(jiffies, last_warning + 5*HZ)) {
    printk(KERN_NOTICE "ENOMEM in %s, retrying.\n",
    last_warning = jiffies;
    while (ret == NULL) {
    ret = kmem_cache_alloc(journal_head_cache, GFP_NOFS);

    Like journal_write_metadata_buffer(), which you quoted, it's called
    out of the commit code, where about the only choice we have other than
    looping or using GFP_NOFAIL is to abort the filesystem and remount it
    read-only or panic. It's not at all clear to me that looping
    repeatedly is helpful; for example, the allocator doesn't know that it
    should try really hard, and perhaps fall back to an order 0 allocation
    of an order 1 allocation won't work.

    Hmm.... it may be possible to do the memory allocation in advance,
    before we get to the commit, and make it be easier to fail and return
    ENOMEM to userspace --- which I bet most applications won't handle
    gracefully, either (a) not checking error codes and losing data, or
    (b) dieing on the spot, so it would be effectively be an OOM kill.
    And in some cases, we're calling journal_get_write_access() out of a
    kernel daemon like pdflush, where the error recovery paths may get
    rather interesting.

    The question then is what is the right strategy? Use GFP_NOFAIL, and
    let the memory allocator loop; let the allocating kernel code loop;
    remount filesystems read/only and/or panic; pass a "try _really_ hard"
    flag to the allocator and fall back to a ro-remount/panic if the
    allocator still wasn't successful? None of the alternatives seem
    particularly appealing to me....

    - Ted

     \ /
      Last update: 2009-06-25 15:29    [W:0.022 / U:20.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site