Lines Matching +full:two +full:- +full:user
68 pp. 295-303, June 1988.
99 patterns in the UNIX kernel and a hybrid strategy that is time-efficient
100 for small allocations and space-efficient for large allocations.
102 with a single easy-to-program interface,
120 In a user process such short-term
121 memory would be allocated on the run-time stack.
122 Because the kernel has a limited run-time stack,
159 Rather than providing many semi-specialized ways of allocating memory,
170 of the well-known memory allocator provided for
186 the design criteria for a user level memory allocator.
214 in user processes.
215 Because user processes run in virtual memory,
225 rather than to hold it as is typically done with user processes.
228 a user process must do a system call to release memory.
234 kernel than in user code,
235 because the kernel must allocate many data structure that user
236 processes can allocate cheaply on their run-time stack.
237 In addition, the kernel represents the platform on which all user
243 of frequently-used kernel interfaces will feel that they
251 consider the case of two subsystems that need memory.
253 the amount of memory tied up in the two lists will be the
255 the two subsystems has ever used.
261 .H 1 "Existing User-level Implementations
264 implementations of user-level memory allocators.
268 The fastest memory allocator in the survey by nearly a factor of two
275 The 4.2BSD user-level memory allocator works by maintaining a set of lists
276 that are ordered by increasing powers of two.
279 the size of the request is rounded up to the next power of two.
281 to the specified power of two and returned to the requester.
283 a block from the 64-sized list.
294 memory allocator for the kernel that do not apply to a user process
306 For a user process, the maximum amount of memory that may be allocated
318 Unlike user processes that can only grow and shrink their heap at one end,
321 The effect is much the same as a user process that has parts of
327 .FI "One day memory usage on a Berkeley time-sharing machine"
358 and are typically for long-lived objects
369 and a slower but more-memory-efficient first-fit allocator.
371 Small allocations are done using the 4.2BSD power-of-two list strategy;
391 Because of the inefficiency of power-of-two allocation strategies
393 a different strategy is used for allocations larger than two kilobytes.
394 The selection of two kilobytes is derived from our statistics on
406 observes that the power-of-two algorithm yields sizes of 1, 2, 4, 8, \&...
409 Thus for allocations of sizes between one and two pages
410 both algorithms use two pages;
411 it is not until allocations of sizes between two and three pages
412 that a difference emerges where the power-of-two algorithm will use
416 so two kilobytes is the smallest logical cutoff.
419 The allocator then uses a first-fit algorithm to find space in the
423 the power-of-two allocation strategy.
431 is to cluster same-sized small allocations on a page.
432 When a list for a power-of-two allocation is empty,
442 The 4.2BSD user-level allocator stores the size of each block
445 require a power-of-two-sized block.
456 memory whose size is exactly a power of two.
457 These requests would be nearly doubled if the user-level strategy were used.
518 of the running time of the multi-purpose routines that could
537 significant new run-time costs.
540 on a per-page basis.
552 Making these tables dynamic will have two benefits.
589 most allocations are short-lived, lasting only for the duration of
609 it manages the constant-sized buffer pool.
628 David Korn, Kiem-Phong Vo,
631 pp 489-506, June 1985.
636 pp 519-531, June 1985.
646 pp 1931-1946, 1978.