[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EA69BE2.3020703@ilyx.ru>
Date: Tue, 25 Oct 2011 15:22:10 +0400
From: Ilya Zykov <ilya@...x.ru>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Greg Kroah-Hartman <gregkh@...e.de>,
Alan Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TTY: tty flip buffer change reserve memory strategy.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists