Messages in this thread |  | | From | Marek Michalkiewicz <> | Subject | Re: 2.2.0 wishlist | Date | Fri, 14 Jun 1996 19:19:09 +0200 (MET DST) |
| |
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
|  |