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-2011 Jasper Spaans