Best way to extend try_to_free_pages()?

From: Andreas Bombe (andreas.bombe@munich.netsurf.de)
Date: Tue May 16 2000 - 17:58:29 EST


I will implement, for the ieee 1394 subsystem, a revised buffer for
received isochronous packets. These are streams which can amount to
quite a lot of data when 400 MBit/s are fully used (almost fully by
standards, to be correct). These need to be buffered in the kernel
until a user space program handling those gets scheduled to pick them
up. If noone picks them up in time, packets will be freed and therefore
get lost which is the application's problem.

The question is when to start freeing:

1. Allocation for newly arrived packet fails -> reuse old packet. The
   problem with this is that when this happens probably quite a
   significant amount of memory is already used by our unswappable
   buffers and we take the machine to a grinding halt because an app
   (temporarily) can't keep up with the data.

2. Allocate only to a fixed maximum buffer size. This is what I do
   now. Better, but the maximum depends on the machine in use and on
   the dynamic load. On loaded machines we still could eat all
   remaining memory.

3. do_try_to_free_pages() calls an 1394 subsystem function asking to
   free memory. My favourite, the most flexible.

Is there any way to hook something into the page freeing routine in
the current code short of adding it to do_try_to_free_pages() directly
(not possible, since 1394 code can be modularized)? If not, I
consider adding some generic code to register callbacks for low memory
situations as soon as I need it.

Since I don't know memory handling as well as other parts I'm asking
for comments and suggestions here.

-- 
 Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

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



This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:11 EST