On Fri, Dec 30, 2005 at 11:42:44PM +0100, Peter Zijlstra wrote:
>
> From: Peter Zijlstra <[email protected]>
>
> Originally started by Rik van Riel, I heavily modified the code
> to suit my needs.
>
> The nonresident code approximates a clock but sacrifices precision in order
> to accomplish faster lookups.
>
> The actual datastructure is a hash of small clocks, so that, assuming an
> equal distribution by the hash function, each clock has comparable order.
>
> TODO:
> - remove the ARC requirements.
>
> Signed-off-by: Peter Zijlstra <[email protected]>
<snip>
> + *
> + *
> + * Modified to work with ARC like algorithms who:
> + * - need to balance two FIFOs; |b1| + |b2| = c,
> + *
> + * The bucket contains four single linked cyclic lists (CLOCKS) and each
> + * clock has a tail hand. By selecting a victim clock upon insertion it
> + * is possible to balance them.
> + *
> + * The first two lists are used for B1/B2 and a third for a free slot list.
> + * The fourth list is unused.
> + *
> + * The slot looks like this:
> + * struct slot_t {
> + * u32 cookie : 24; // LSB
> + * u32 index : 6;
> + * u32 listid : 2;
> + * };
8 and 16 bit accesses are slower than 32 bit on i386 (Arjan pointed this out sometime ago).
Might be faster to load a full word and shape it as necessary, will see if I can do
something instead of talking. ;)
> +/*
> + * For interactive workloads, we remember about as many non-resident pages
> + * as we have actual memory pages. For server workloads with large inter-
> + * reference distances we could benefit from remembering more.
> + */
This comment is bogus. Interactive or server loads have nothing to do
with the inter reference distance. To the contrary, interactive loads
have a higher chance to contain large inter reference distances, and
many common server loads have strong locality.
<snip>
> +++ linux-2.6-git/include/linux/swap.h
> @@ -152,6 +152,31 @@ extern void out_of_memory(gfp_t gfp_mask
> /* linux/mm/memory.c */
> extern void swapin_readahead(swp_entry_t, unsigned long, struct vm_area_struct *);
>
> +/* linux/mm/nonresident.c */
> +#define NR_b1 0
> +#define NR_b2 1
> +#define NR_free 2
> +#define NR_lost 3
What is the meaning of "NR_lost" ?
> +
> +#define NR_listid 3
> +#define NR_found 0x80000000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
