Messages in this thread | | | Date | Tue, 25 Oct 2011 08:45:43 +0100 | From | Alan Cox <> | Subject | Re: [PATCH] TTY: tty flip buffer change reserve memory strategy. |
| |
> free(kfree()) every chunk more 256 bytes every time, > even we have in free buffer enough space, because we can't > pass through chunk boundary in free buffer. Also we can't limit reserve > memory size. In worse case we will have in free buffer: > (256 * 256 byte chunk) = (256 * 552 ) = 141312 byte unused memory.
The idea is to trade off between the devices that need long linear blocks (mostly for DMA) and devices that don't care - but many of which pass 1 or 2 bytes/irq so want a common buffer.
Most drivers should not be using tty_reserve_room in the first place.
> Also we can limit reserve memory size, but then, > we will be use kmalloc()-kree() calls on intensive stream from the driver.
kmalloc is very fast anyway so I'd be interested in seeing the drivers suffering and the profile traces of a real example.
I'm also not sure I agree with the maths - we chunk buffers to 256 byte boundaries to avoid getting lots of queued buffers of different sizes. We could in fact I think simplify the code from what we have learned using it and simply treat the 256 byte buffer case as special rather than 256 and 512 as we do now. That would let us remove the more generic support for free buffer sizes which is overcomplex and mean we could simply count the number of 256 byte buffers we have to hand.
Alan
| |