src/sys/kern/sys_pipe.c, branch release/5.4.0 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F5.4.0 2005-02-27T02:39:33Z MFC revision 1.178 2005-02-27T02:39:33Z Jeff Roberson jeff@FreeBSD.org 2005-02-27T02:39:33Z urn:sha1:4fcf4a6e6a3927ee0068d2af15b52b4258107f2d - filedesc locking cleanup. MFC: /*- and related license changes 2005-01-31T23:27:04Z Warner Losh imp@FreeBSD.org 2005-01-31T23:27:04Z urn:sha1:c9769f3ab5327a99909391e070c143e92ddc43ec MFC rev 1.183; fix panic when too many pipes are allocated. 2005-01-24T09:03:27Z Mike Silbersack silby@FreeBSD.org 2005-01-24T09:03:27Z urn:sha1:0b9e95c8d8a40b7067dba3f5795409ce8cdb14c3 Major enhancements to pipe memory usage: 2004-08-16T01:27:24Z Mike Silbersack silby@FreeBSD.org 2004-08-16T01:27:24Z urn:sha1:5173e8f5671541c436d00e8b253498b468cf3d49 - pipespace is now able to resize non-empty pipes; this allows for many more resizing opportunities - Backing is no longer pre-allocated for the reverse direction of pipes. This direction is rarely (if ever) used, so this cuts the amount of map space allocated to a pipe in half. - Pipe growth is now much more dynamic; a pipe will now grow when the total amount of data it contains and the size of the write are larger than the size of pipe. Previously, only individual writes greater than the size of the pipe would cause growth. - In low memory situations, pipes will now shrink during both read and write operations, where possible. Once the memory shortage ends, the growth code will cause these pipes to grow back to an appropriate size. - If the full PIPE_SIZE allocation fails when a new pipe is created, the allocation will be retried with SMALL_PIPE_SIZE. This helps to deal with the situation of a fragmented map after a low memory period has ended. - Minor documentation + code changes to support the above. In total, these changes increase the total number of pipes that can be allocated simultaneously, drastically reducing the chances that pipe allocation will fail. Performance appears unchanged due to dynamic resizing. Add locking to the kqueue subsystem. This also makes the kqueue subsystem 2004-08-15T06:24:42Z John-Mark Gurney jmg@FreeBSD.org 2004-08-15T06:24:42Z urn:sha1:ad3b9257c2f09a6f1c0e56c1100aa4e43fb95e24 a more complete subsystem, and removes the knowlege of how things are implemented from the drivers. Include locking around filter ops, so a module like aio will know when not to be unloaded if there are outstanding knotes using it's filter ops. Currently, it uses the MTX_DUPOK even though it is not always safe to aquire duplicate locks. Witness currently doesn't support the ability to discover if a dup lock is ok (in some cases). Reviewed by: green, rwatson (both earlier versions) Standardize pipe locking, ensuring that everything is locked via 2004-08-03T02:59:15Z Mike Silbersack silby@FreeBSD.org 2004-08-03T02:59:15Z urn:sha1:e10ecdea885deb83b007dbd60fed503e2f194e55 pipelock(), not via a mixture of mutexes and pipelock(). Additionally, add a few KASSERTS, and change some statements that should have been KASSERTS into KASSERTS. As a result of these cleanups, some segments of code have become significantly shorter and/or easier to read. * Add a "how" argument to uma_zone constructors and initialization functions 2004-08-02T00:18:36Z Brian Feldman green@FreeBSD.org 2004-08-02T00:18:36Z urn:sha1:b23f72e98ae8164c07be4b3780a0b83e094844cf so that they know whether the allocation is supposed to be able to sleep or not. * Allow uma_zone constructors and initialation functions to return either success or error. Almost all of the ones in the tree currently return success unconditionally, but mbuf is a notable exception: the packet zone constructor wants to be able to fail if it cannot suballocate an mbuf cluster, and the mbuf allocators want to be able to fail in general in a MAC kernel if the MAC mbuf initializer fails. This fixes the panics people are seeing when they run out of memory for mbuf clusters. * Allow debug.nosleepwithlocks on WITNESS to be disabled, without changing the default. Both bmilekic and jeff have reviewed the changes made to make failable zone allocations work. Don't perform pipe endpoint locking during pipe_create(), as the pipe 2004-07-23T14:11:04Z Robert Watson rwatson@FreeBSD.org 2004-07-23T14:11:04Z urn:sha1:46b25cb5f62cae7c3549e5133f009503cf5eae27 can't yet be referenced by other threads. In microbenchmarks, this appears to reduce the cost of pipe();close();close() on UP by 10%, and SMP by 7%. The vast majority of the cost of allocating a pipe remains VM magic. Suggested by: silby Fix a minor error in pipe_stat - st_size was always reported as 0 2004-07-20T07:06:43Z Mike Silbersack silby@FreeBSD.org 2004-07-20T07:06:43Z urn:sha1:eb3d2c61b44836b51b956726eb887af0a40b738d when direct writes kicked in. Whether this affected any applications is unknown. Revise the direct or optimized case to use uiomove_fromphys() by the reader 2004-03-27T19:50:23Z Alan Cox alc@FreeBSD.org 2004-03-27T19:50:23Z urn:sha1:e3b19536fb495b30f7c24d2adb3004caceaf5da6 instead of ephemeral mappings using pmap_qenter() by the writer. The writer is still, however, responsible for wiring the pages, just not mapping them. Consequently, the allocation of KVA for the direct case is unnecessary. Remove it and the sysctls limiting it, i.e., kern.ipc.maxpipekvawired and kern.ipc.amountpipekvawired. The number of temporarily wired pages is still, however, limited by kern.ipc.maxpipekva. Note: On platforms lacking a direct virtual-to-physical mapping, uiomove_fromphys() uses sf_bufs to cache ephemeral mappings. Thus, the number of available sf_bufs can influence the performance of pipes on platforms such i386. Surprisingly, I saw the greatest gain from this change on such a machine: lmbench's pipe bandwidth result increased from ~1050MB/s to ~1850MB/s on my 2.4GHz, 400MHz FSB P4 Xeon.