Robert Watson <rwatson_at_FreeBSD.org> writes: > I have not yet macro-benchmarked this change. It will either have a > slight performance benefit if half-closed pipes aren't used extensively or > it doesn't make a difference, be a wash, or if half-closed pipes turn up a > lot, potentially slightly negatively impact performance (seems unlikely). [you may want to check the -current archives for silby_at_'s excellent message about pipe memory usage last Tuesday] I think our biggest problem with pipes is not half-open pipes but rather their absence; most of the code that uses pipes only uses one direction and does not bother to shut the other down. This is certainly the case for sh(1) and make(1), which I suspect are the heaviest pipe consumers in a typical system (especially in one running our favorite benchmark tool, 'make buildworld'.) The result is that we use almost twice as much memory for pipes as we need to. * solution: allocate pipe buffers on first-use rather than at pipe creation time. Another problem with pipes is that the default pipe buffer size is too large. * solution: reduce the initial allocation to a single page, and grow the buffer later if necessary (up to a limit og four or eight pages) One problem we can't solve easily is the fact that pipe buffers are allocated directly from the pipe vm map, which is a very inefficient operation in FreeBSD. I have a tentative design in my notebook for a more efficient data structure for vm maps, allowing vm_map_find() to run in logarithmic rather than linear time, but this hasn't been high on my priority list as it's fairly hard to get right. BTW, as I am currently working on some of these issues, I'd be happy if you could commit your patches fairly quickly so I don't have to start all over again once they hit the tree. DES -- Dag-Erling Smørgrav - des_at_des.noReceived on Sat Jan 31 2004 - 19:46:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:41 UTC