lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ