lkml.org 
[lkml]   [1996]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 2.2.0 wishlist
    Date
    Stephen Tweedie:
    > Look again. This is implemented in 2.0. See linux/drivers/char/random.c,
    > function secure_tcp_sequence_number().

    Yes, there is secure_tcp_sequence_number(), but it is not used
    anywhere, and the tcp code still uses do_gettimeofday(). I guess
    it was too late before 2.0 to change that... Too bad, it would
    be another argument for NOT making the random driver optional :-).

    > Impossible. DMA *needs* contiguous memory, and how you allocate

    I know. But perhaps it would be possible to change the way memory
    is allocated so that it tries to minimize fragmentation. I am not
    an expert here, so please tell me if it totally doesn't make sense,
    but here are a few ideas (unless it is already done this way):

    - when allocating a single non-DMA free page, try to find one which
    has the highest physical address, to keep as much free contiguous
    low memory as possible

    - when allocating a larger non-DMA area (consisting of several
    pages), allocate each page as described above, then modify the
    page tables so that they appear contiguous in the virtual address
    space (even if they are not physically contiguous)

    - __get_free_pages() currently quits calling try_to_free_page()
    as soon as (nr_free_pages > reserved_pages) even though this does
    not mean that there are enough free contiguous pages. The code
    from linux/mm/page_alloc.c (lines 193-203) looks like this:
    repeat:
    cli();
    if ((priority==GFP_ATOMIC) || nr_free_pages > reserved_pages) {
    RMQUEUE(order, dma);
    restore_flags(flags);
    return 0;
    }
    restore_flags(flags);
    if (priority != GFP_BUFFER && try_to_free_page(priority, dma, 1))
    goto repeat;
    return 0;
    I haven't tried that yet, but how about something like this instead:

    repeat:
    cli();
    if ((priority==GFP_ATOMIC) || nr_free_pages > reserved_pages) {
    RMQUEUE(order, dma);
    }
    restore_flags(flags);
    if (priority != GFP_BUFFER && priority != GFP_ATOMIC &&
    try_to_free_page(priority, dma, 1))
    goto repeat;
    return 0;
    This way (except for GFP_BUFFER and GFP_ATOMIC), if the first attempt
    fails, we keep calling try_to_free_page() until it fails and breaks
    the loop. Or would it cause a lockup under some circumstances?

    The problem is not limited to DMA - I got some failures with ncpfs
    directory cache allocations, which I believe are caused by the above
    discussed __get_free_pages() behaviour.

    Regards,

    Marek


    \
     
     \ /
      Last update: 2005-03-22 13:37    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean