Re: [PATCH 1/11] maps3: add proportional set size accounting in smaps

[David Rientjes <rientjes@google.com>]

On Mon, 15 Oct 2007, Matt Mackall wrote:

> Index: l/fs/proc/task_mmu.c
> ===================================================================
> --- l.orig/fs/proc/task_mmu.c	2007-10-14 13:35:31.000000000 -0500
> +++ l/fs/proc/task_mmu.c	2007-10-14 13:36:56.000000000 -0500
> @@ -122,6 +122,27 @@ struct mem_size_stats
>  	unsigned long private_clean;
>  	unsigned long private_dirty;
>  	unsigned long referenced;
> +
> +	/*
> +	 * Proportional Set Size(PSS): my share of RSS.
> +	 *
> +	 * PSS of a process is the count of pages it has in memory, where each
> +	 * page is divided by the number of processes sharing it.  So if a
> +	 * process has 1000 pages all to itself, and 1000 shared with one other
> +	 * process, its PSS will be 1500.               - Matt Mackall, lwn.net
> +	 */
> +	u64 	      pss;
> +	/*
> +	 * To keep (accumulated) division errors low, we adopt 64bit pss and
> +	 * use some low bits for division errors. So (pss >> PSS_DIV_BITS)
> +	 * would be the real byte count.
> +	 *
> +	 * A shift of 12 before division means(assuming 4K page size):
> +	 * 	- 1M 3-user-pages add up to 8KB errors;
> +	 * 	- supports mapcount up to 2^24, or 16M;
> +	 * 	- supports PSS up to 2^52 bytes, or 4PB.
> +	 */
> +#define PSS_DIV_BITS	12
>  };
>  

I know this gets moved again in the eighth patch of the series, but the 
#define still has no place inside the struct definition.

The pss is going to need accessor functions, preferably inlined, and the 
comment adjusted stating that all accesses should be through those 
functions and not directly to the mem_size_stats struct.

	static inline u64 pss_up(unsigned long pss)
	{
		return pss << PSS_DIV_BITS;
	}

	static inline unsigned long pss_down(u64 pss)
	{
		return pss >> PSS_DIV_BITS;
	}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/