Re: [PATCH] TTY: tty flip buffer change reserve memory strategy.

[Ilya Zykov <ilya@ilyx.ru>]

Thank you, for answer.

> 
> kmalloc is very fast anyway so I'd be interested in seeing the drivers
> suffering and the profile traces of a real example.
> 

Pty use chunk more 256 bytes very often. More program for communicate with
pppd use pty master - slave. If often kmalloc()-kfree() calls don't provoke
memory fragmentation and flush TLB, I agree it isn't important.


> 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.

Now we can't accumulate buffer more than 256 byte. 
"if (b->size >= 512) kfree(b);" and our buffer can be only 256, 512 ... .
We can simplify tty_buffer_find() for don't look up buffer more 256 byte.

I think my patch very clear, because if stream from driver very slow we 
will be use only two 256 byte chunk, as before. But with pty, maybe, new drivers,
we could use flip buffer more effective.

Ilya.