Date: Sun, 8 Jan 2012 03:35:47 +0100 From: Giovanni Trematerra <gianni@freebsd.org> To: freebsd-arch@freebsd.org, jilles@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, flo@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: pipe/fifo code merged. Message-ID: <CACfq093o9iVZKxCj58OR2hpCLDYTUTdxg_re_bEMYn2SrNrLCQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, the patch at http://www.trematerra.net/patches/pipefifo_merge2.diff is a preliminary version of the FIFO optimizations project that I picked up from the wiki. http://wiki.freebsd.org/IdeasPage#FIFO_optimizations_.28GSoC.29 zhaoshuai@ produced the following patch in the 2009 which attempted a first merge of the interfaces: http://www.trematerra.net/patches/fifo_soc2009.diff However I felt like the work was not yet completed and come up with my final version. Now fifoes derive their structures from pipes one with just special handling to support VFS operations. All the operations but the creation/destruction for fifoes and pipes are handled by the same code. The heart of the patch is the new struct pipeinfo. pipeinfo is a per-file descriptor state. Basically it maintains a read end and a write end for the descriptor. As pipes are bidirectional in FreeBSD, for a pipe this two fields are always equal but different for a fifo. To let fifo code in sys/fs/fifofs/fifo_vnops.c create/destroy the pipe, two functions (pipe_ctor/pipe_dtor) were written. pipe_ctor setups things like a call to kern_pipe and return a pipeinfo structure, while pipe_dtor releases all the resources for a given pipeinfo. Once a pipe was setup during a fifo_open call, all the subsequent operations on the fifo are handled by the same code of a pipe expect for the clean up code that calls pipe_dtor. Allocation of two pipeinfo structures for a pipe were showed to slow down things by some micro-benchmarking. To speed up things during creation/destruction of pipes, the patch allocates all the needed data structure zone using the umapipe struct that packing together all the needed data structures to be allocated at pipe creation. A similar umafifo structure is used for fifoes. Thanks to jilles that made a review of the patch in a previous form, privately. Thanks a lot to attilio that answered my stupid questions and drove me in the right direction. TEST The patch passed all the test in tools/regression/pipe and tools/regression/fifo it passed a overnight of running stress test pho's suite and some buildworld/buildkernel of FreeBSD HEAD. PERFORMANCE the patch doesn't add any performance penalty at pipe code, the test was performed by compiling a GENERIC kernel. There's a lot of pipe code involving during a compilation. Such a test was used to discovery a performance regression in r226042. this is the ministat output http://www.trematerra.net/patches/pipeperf/pipeperf_result here the raw data http://www.trematerra.net/patches/pipeperf/pipeperf_rawresult The new fifo implementation gives to fifoes a boost of at least 15% in avarage. The test was send 1000 chunk of different size through a fifo. here the output of ministat output http://www.trematerra.net/patches/fifoperf/fifoperf_result here the raw results http://www.trematerra.net/patches/fifoperf/fifoperf_rawresult if someone would like to reproduce the test can download a copy of the sources a http://www.trematerra.net/patches/fifoperf/ the code is from zhaoshuai@. Makefile, builds benchmark.c benchmark.c set up a fifo, fork and send a number of messages of a size depending from the input parameters. runme.sh run the test launching benchmark binary to send different number of messages of different sizes. Test and review are welcomed. -- Gianni
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACfq093o9iVZKxCj58OR2hpCLDYTUTdxg_re_bEMYn2SrNrLCQ>