[PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

Export mlock(wired) info through file /proc/meminfo.

Signed-off-by: Shaoping Wang <pwstone@gmail.com>

--
 fs/proc/proc_misc.c    |    5 ++++-
 include/linux/mm.h     |    4 ++++
 include/linux/mmzone.h |    4 ++--
 mm/page_alloc.c        |   26 +++++++++++++++++++-------
 mm/readahead.c         |    3 ++-
 5 files changed, 31 insertions(+), 11 deletions(-)

diff -urN linux-2.6.15.orig/fs/proc/proc_misc.c linux-2.6.15/fs/proc/proc_misc.c
--- linux-2.6.15.orig/fs/proc/proc_misc.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/fs/proc/proc_misc.c	2006-03-06 06:44:50.000000000 -0500
@@ -123,6 +123,7 @@
 	struct page_state ps;
 	unsigned long inactive;
 	unsigned long active;
+	unsigned long wired;
 	unsigned long free;
 	unsigned long committed;
 	unsigned long allowed;
@@ -130,7 +131,7 @@
 	long cached;

 	get_page_state(&ps);
-	get_zone_counts(&active, &inactive, &free);
+	get_zone_counts(&active, &inactive, &wired, &free);

 /*
  * display in kilobytes.
@@ -159,6 +160,7 @@
 		"SwapCached:   %8lu kB\n"
 		"Active:       %8lu kB\n"
 		"Inactive:     %8lu kB\n"
+		"Wired:        %8lu kB\n"
 		"HighTotal:    %8lu kB\n"
 		"HighFree:     %8lu kB\n"
 		"LowTotal:     %8lu kB\n"
@@ -182,6 +184,7 @@
 		K(total_swapcache_pages),
 		K(active),
 		K(inactive),
+		K(wired),
 		K(i.totalhigh),
 		K(i.freehigh),
 		K(i.totalram-i.totalhigh),
diff -urN linux-2.6.15.orig/include/linux/mmzone.h
linux-2.6.15/include/linux/mmzone.h
--- linux-2.6.15.orig/include/linux/mmzone.h	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/include/linux/mmzone.h	2006-03-07 01:58:26.000000000 -0500
@@ -315,9 +317,9 @@
 extern struct pglist_data *pgdat_list;

 void __get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free, struct pglist_data *pgdat);
+		unsigned long *wired, unsigned long *free, struct pglist_data *pgdat);
 void get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free);
+		unsigned long *wired, unsigned long *free);
 void build_all_zonelists(void);
 void wakeup_kswapd(struct zone *zone, int order);
 int zone_watermark_ok(struct zone *z, int order, unsigned long mark,
diff -urN linux-2.6.15.orig/mm/page_alloc.c linux-2.6.15/mm/page_alloc.c
--- linux-2.6.15.orig/mm/page_alloc.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/mm/page_alloc.c	2006-03-06 06:30:08.000000000 -0500
@@ -1252,35 +1254,39 @@
 EXPORT_SYMBOL(__mod_page_state);

 void __get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free, struct pglist_data *pgdat)
+			unsigned long *wired,unsigned long *free, struct pglist_data *pgdat)
 {
 	struct zone *zones = pgdat->node_zones;
 	int i;

 	*active = 0;
 	*inactive = 0;
+	*wired = 0;
 	*free = 0;
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		*active += zones[i].nr_active;
 		*inactive += zones[i].nr_inactive;
+		*wired += zones[i].nr_wired;
 		*free += zones[i].free_pages;
 	}
 }

 void get_zone_counts(unsigned long *active,
-		unsigned long *inactive, unsigned long *free)
+		unsigned long *inactive, unsigned long *wired, unsigned long *free)
 {
 	struct pglist_data *pgdat;

 	*active = 0;
 	*inactive = 0;
+	*wired = 0;
 	*free = 0;
 	for_each_pgdat(pgdat) {
-		unsigned long l, m, n;
-		__get_zone_counts(&l, &m, &n, pgdat);
+		unsigned long l, m, n, o;
+		__get_zone_counts(&l, &m, &n, &o, pgdat);
 		*active += l;
 		*inactive += m;
-		*free += n;
+		*wired += n;
+		*free += o;
 	}
 }

@@ -1328,6 +1334,7 @@
 	int cpu, temperature;
 	unsigned long active;
 	unsigned long inactive;
+	unsigned long wired;
 	unsigned long free;
 	struct zone *zone;

@@ -1358,16 +1365,17 @@
 	}

 	get_page_state(&ps);
-	get_zone_counts(&active, &inactive, &free);
+	get_zone_counts(&active, &inactive, &wired, &free);

 	printk("Free pages: %11ukB (%ukB HighMem)\n",
 		K(nr_free_pages()),
 		K(nr_free_highpages()));

-	printk("Active:%lu inactive:%lu dirty:%lu writeback:%lu "
+	printk("Active:%lu inactive:%lu wired:%lu dirty:%lu writeback:%lu "
 		"unstable:%lu free:%u slab:%lu mapped:%lu pagetables:%lu\n",
 		active,
 		inactive,
+		wired,
 		ps.nr_dirty,
 		ps.nr_writeback,
 		ps.nr_unstable,
@@ -1387,6 +1395,7 @@
 			" high:%lukB"
 			" active:%lukB"
 			" inactive:%lukB"
+			" wired:%lukB"
 			" present:%lukB"
 			" pages_scanned:%lu"
 			" all_unreclaimable? %s"
@@ -1398,6 +1407,7 @@
 			K(zone->pages_high),
 			K(zone->nr_active),
 			K(zone->nr_inactive),
+			K(zone->nr_wired),
 			K(zone->present_pages),
 			zone->pages_scanned,
 			(zone->all_unreclaimable ? "yes" : "no")
@@ -2009,10 +2019,12 @@
 		zone_pcp_init(zone);
 		INIT_LIST_HEAD(&zone->active_list);
 		INIT_LIST_HEAD(&zone->inactive_list);
+		INIT_LIST_HEAD(&zone->wired_list);
 		zone->nr_scan_active = 0;
 		zone->nr_scan_inactive = 0;
 		zone->nr_active = 0;
 		zone->nr_inactive = 0;
+		zone->nr_wired = 0;
 		atomic_set(&zone->reclaim_in_progress, 0);
 		if (!size)
 			continue;
@@ -2161,6 +2173,7 @@
 			   "\n        high     %lu"
 			   "\n        active   %lu"
 			   "\n        inactive %lu"
+			   "\n        wired    %lu"
 			   "\n        scanned  %lu (a: %lu i: %lu)"
 			   "\n        spanned  %lu"
 			   "\n        present  %lu",
@@ -2170,6 +2183,7 @@
 			   zone->pages_high,
 			   zone->nr_active,
 			   zone->nr_inactive,
+			   zone->nr_wired,
 			   zone->pages_scanned,
 			   zone->nr_scan_active, zone->nr_scan_inactive,
 			   zone->spanned_pages,
diff -urN linux-2.6.15.orig/include/linux/mm.h linux-2.6.15/include/linux/mm.h
--- linux-2.6.15.orig/include/linux/mm.h	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/include/linux/mm.h	2006-03-07 01:49:12.000000000 -0500
@@ -218,6 +221,10 @@
 	unsigned long flags;		/* Atomic flags, some possibly
 					 * updated asynchronously */
 	atomic_t _count;		/* Usage count, see below. */
+	unsigned short wired_count; /* Count of wirings of the page.
+					 * If not zero,the page would be SetPageWired,
+					 * and put on Wired list of the zone.
+					 */
 	atomic_t _mapcount;		/* Count of ptes mapped in mms,
 					 * to show when page is mapped
 					 * & limit reverse map searches.
diff -urN linux-2.6.15.orig/mm/readahead.c linux-2.6.15/mm/readahead.c
--- linux-2.6.15.orig/mm/readahead.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/mm/readahead.c	2006-03-06 06:30:08.000000000 -0500
@@ -564,8 +564,9 @@
 {
 	unsigned long active;
 	unsigned long inactive;
+	unsigned long wired;
 	unsigned long free;

-	__get_zone_counts(&active, &inactive, &free, NODE_DATA(numa_node_id()));
+	__get_zone_counts(&active, &inactive, &wired, &free,
NODE_DATA(numa_node_id()));
 	return min(nr, (inactive + free) / 2);
 }

[PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

Export mlock(wired) info through file /proc/meminfo.

Signed-off-by: Shaoping Wang <pwstone@gmail.com>

--
 fs/proc/proc_misc.c    |    5 ++++-
 include/linux/mm.h     |    4 ++++
 include/linux/mmzone.h |    4 ++--
 mm/page_alloc.c        |   26 +++++++++++++++++++-------
 mm/readahead.c         |    3 ++-
 5 files changed, 31 insertions(+), 11 deletions(-)

diff -urN linux-2.6.15.orig/fs/proc/proc_misc.c linux-2.6.15/fs/proc/proc_misc.c
--- linux-2.6.15.orig/fs/proc/proc_misc.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/fs/proc/proc_misc.c	2006-03-06 06:44:50.000000000 -0500
@@ -123,6 +123,7 @@
 	struct page_state ps;
 	unsigned long inactive;
 	unsigned long active;
+	unsigned long wired;
 	unsigned long free;
 	unsigned long committed;
 	unsigned long allowed;
@@ -130,7 +131,7 @@
 	long cached;

 	get_page_state(&ps);
-	get_zone_counts(&active, &inactive, &free);
+	get_zone_counts(&active, &inactive, &wired, &free);

 /*
  * display in kilobytes.
@@ -159,6 +160,7 @@
 		"SwapCached:   %8lu kB\n"
 		"Active:       %8lu kB\n"
 		"Inactive:     %8lu kB\n"
+		"Wired:        %8lu kB\n"
 		"HighTotal:    %8lu kB\n"
 		"HighFree:     %8lu kB\n"
 		"LowTotal:     %8lu kB\n"
@@ -182,6 +184,7 @@
 		K(total_swapcache_pages),
 		K(active),
 		K(inactive),
+		K(wired),
 		K(i.totalhigh),
 		K(i.freehigh),
 		K(i.totalram-i.totalhigh),
diff -urN linux-2.6.15.orig/include/linux/mmzone.h
linux-2.6.15/include/linux/mmzone.h
--- linux-2.6.15.orig/include/linux/mmzone.h	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/include/linux/mmzone.h	2006-03-07 01:58:26.000000000 -0500
@@ -315,9 +317,9 @@
 extern struct pglist_data *pgdat_list;

 void __get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free, struct pglist_data *pgdat);
+		unsigned long *wired, unsigned long *free, struct pglist_data *pgdat);
 void get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free);
+		unsigned long *wired, unsigned long *free);
 void build_all_zonelists(void);
 void wakeup_kswapd(struct zone *zone, int order);
 int zone_watermark_ok(struct zone *z, int order, unsigned long mark,
diff -urN linux-2.6.15.orig/mm/page_alloc.c linux-2.6.15/mm/page_alloc.c
--- linux-2.6.15.orig/mm/page_alloc.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/mm/page_alloc.c	2006-03-06 06:30:08.000000000 -0500
@@ -1252,35 +1254,39 @@
 EXPORT_SYMBOL(__mod_page_state);

 void __get_zone_counts(unsigned long *active, unsigned long *inactive,
-			unsigned long *free, struct pglist_data *pgdat)
+			unsigned long *wired,unsigned long *free, struct pglist_data *pgdat)
 {
 	struct zone *zones = pgdat->node_zones;
 	int i;

 	*active = 0;
 	*inactive = 0;
+	*wired = 0;
 	*free = 0;
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		*active += zones[i].nr_active;
 		*inactive += zones[i].nr_inactive;
+		*wired += zones[i].nr_wired;
 		*free += zones[i].free_pages;
 	}
 }

 void get_zone_counts(unsigned long *active,
-		unsigned long *inactive, unsigned long *free)
+		unsigned long *inactive, unsigned long *wired, unsigned long *free)
 {
 	struct pglist_data *pgdat;

 	*active = 0;
 	*inactive = 0;
+	*wired = 0;
 	*free = 0;
 	for_each_pgdat(pgdat) {
-		unsigned long l, m, n;
-		__get_zone_counts(&l, &m, &n, pgdat);
+		unsigned long l, m, n, o;
+		__get_zone_counts(&l, &m, &n, &o, pgdat);
 		*active += l;
 		*inactive += m;
-		*free += n;
+		*wired += n;
+		*free += o;
 	}
 }

@@ -1328,6 +1334,7 @@
 	int cpu, temperature;
 	unsigned long active;
 	unsigned long inactive;
+	unsigned long wired;
 	unsigned long free;
 	struct zone *zone;

@@ -1358,16 +1365,17 @@
 	}

 	get_page_state(&ps);
-	get_zone_counts(&active, &inactive, &free);
+	get_zone_counts(&active, &inactive, &wired, &free);

 	printk("Free pages: %11ukB (%ukB HighMem)\n",
 		K(nr_free_pages()),
 		K(nr_free_highpages()));

-	printk("Active:%lu inactive:%lu dirty:%lu writeback:%lu "
+	printk("Active:%lu inactive:%lu wired:%lu dirty:%lu writeback:%lu "
 		"unstable:%lu free:%u slab:%lu mapped:%lu pagetables:%lu\n",
 		active,
 		inactive,
+		wired,
 		ps.nr_dirty,
 		ps.nr_writeback,
 		ps.nr_unstable,
@@ -1387,6 +1395,7 @@
 			" high:%lukB"
 			" active:%lukB"
 			" inactive:%lukB"
+			" wired:%lukB"
 			" present:%lukB"
 			" pages_scanned:%lu"
 			" all_unreclaimable? %s"
@@ -1398,6 +1407,7 @@
 			K(zone->pages_high),
 			K(zone->nr_active),
 			K(zone->nr_inactive),
+			K(zone->nr_wired),
 			K(zone->present_pages),
 			zone->pages_scanned,
 			(zone->all_unreclaimable ? "yes" : "no")
@@ -2009,10 +2019,12 @@
 		zone_pcp_init(zone);
 		INIT_LIST_HEAD(&zone->active_list);
 		INIT_LIST_HEAD(&zone->inactive_list);
+		INIT_LIST_HEAD(&zone->wired_list);
 		zone->nr_scan_active = 0;
 		zone->nr_scan_inactive = 0;
 		zone->nr_active = 0;
 		zone->nr_inactive = 0;
+		zone->nr_wired = 0;
 		atomic_set(&zone->reclaim_in_progress, 0);
 		if (!size)
 			continue;
@@ -2161,6 +2173,7 @@
 			   "\n        high     %lu"
 			   "\n        active   %lu"
 			   "\n        inactive %lu"
+			   "\n        wired    %lu"
 			   "\n        scanned  %lu (a: %lu i: %lu)"
 			   "\n        spanned  %lu"
 			   "\n        present  %lu",
@@ -2170,6 +2183,7 @@
 			   zone->pages_high,
 			   zone->nr_active,
 			   zone->nr_inactive,
+			   zone->nr_wired,
 			   zone->pages_scanned,
 			   zone->nr_scan_active, zone->nr_scan_inactive,
 			   zone->spanned_pages,
diff -urN linux-2.6.15.orig/include/linux/mm.h linux-2.6.15/include/linux/mm.h
--- linux-2.6.15.orig/include/linux/mm.h	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/include/linux/mm.h	2006-03-07 01:49:12.000000000 -0500
@@ -218,6 +221,10 @@
 	unsigned long flags;		/* Atomic flags, some possibly
 					 * updated asynchronously */
 	atomic_t _count;		/* Usage count, see below. */
+	unsigned short wired_count; /* Count of wirings of the page.
+					 * If not zero,the page would be SetPageWired,
+					 * and put on Wired list of the zone.
+					 */
 	atomic_t _mapcount;		/* Count of ptes mapped in mms,
 					 * to show when page is mapped
 					 * & limit reverse map searches.
diff -urN linux-2.6.15.orig/mm/readahead.c linux-2.6.15/mm/readahead.c
--- linux-2.6.15.orig/mm/readahead.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15/mm/readahead.c	2006-03-06 06:30:08.000000000 -0500
@@ -564,8 +564,9 @@
 {
 	unsigned long active;
 	unsigned long inactive;
+	unsigned long wired;
 	unsigned long free;

-	__get_zone_counts(&active, &inactive, &free, NODE_DATA(numa_node_id()));
+	__get_zone_counts(&active, &inactive, &wired, &free,
NODE_DATA(numa_node_id()));
 	return min(nr, (inactive + free) / 2);
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> Export mlock(wired) info through file /proc/meminfo.
> 

If wired is solely for mlock pages... why not just call it
mlock/mlocked?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> Export mlock(wired) info through file /proc/meminfo.
> 

If wired is solely for mlock pages... why not just call it
mlock/mlocked?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

The list potentially could have more wider use.

For example, kernel-space locked/pinned pages could be placed on the list too
(while mlocked pages are locked/pinned by system calls from user-space).

2006/3/21, Nick Piggin <nickpiggin@yahoo.com.au>:
> Stone Wang wrote:
> > Export mlock(wired) info through file /proc/meminfo.
> >
>
> If wired is solely for mlock pages... why not just call it
> mlock/mlocked?
>
> --
> SUSE Labs, Novell Inc.
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

The list potentially could have more wider use.

For example, kernel-space locked/pinned pages could be placed on the list too
(while mlocked pages are locked/pinned by system calls from user-space).

2006/3/21, Nick Piggin <nickpiggin@yahoo.com.au>:
> Stone Wang wrote:
> > Export mlock(wired) info through file /proc/meminfo.
> >
>
> If wired is solely for mlock pages... why not just call it
> mlock/mlocked?
>
> --
> SUSE Labs, Novell Inc.
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Arjan van de Ven]

On Tue, 2006-03-21 at 10:33 -0500, Stone Wang wrote:
> The list potentially could have more wider use.
> 
> For example, kernel-space locked/pinned pages could be placed on the list too
> (while mlocked pages are locked/pinned by system calls from user-space).

then please call it pinned_list or locked_down_list or so ;)

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Arjan van de Ven]

On Tue, 2006-03-21 at 10:33 -0500, Stone Wang wrote:
> The list potentially could have more wider use.
> 
> For example, kernel-space locked/pinned pages could be placed on the list too
> (while mlocked pages are locked/pinned by system calls from user-space).

then please call it pinned_list or locked_down_list or so ;)


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> The list potentially could have more wider use.
> 
> For example, kernel-space locked/pinned pages could be placed on the list too
> (while mlocked pages are locked/pinned by system calls from user-space).
> 

kernel-space pages are always pinned. And no, you can't put them on the list
because you never know if their ->lru field is going to be used for something
else.

Why would you want to ever do something like that though? I don't think you
should use this name "just in case", unless you have some really good
potential usage in mind.

---
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> The list potentially could have more wider use.
> 
> For example, kernel-space locked/pinned pages could be placed on the list too
> (while mlocked pages are locked/pinned by system calls from user-space).
> 

kernel-space pages are always pinned. And no, you can't put them on the list
because you never know if their ->lru field is going to be used for something
else.

Why would you want to ever do something like that though? I don't think you
should use this name "just in case", unless you have some really good
potential usage in mind.

---
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

The name "Wired" could be changed to which one most kids think better
fits the job.

I choosed "Wired" for:
"Locked" will conflict with PG_locked bit of a pags.
"Pinned" indicates a short-term lock,so not fits the job too.

Shaoping Wang

2006/3/21, Nick Piggin <nickpiggin@yahoo.com.au>:
> Stone Wang wrote:
> > The list potentially could have more wider use.
> >
> > For example, kernel-space locked/pinned pages could be placed on the list too
> > (while mlocked pages are locked/pinned by system calls from user-space).
> >
>
> kernel-space pages are always pinned. And no, you can't put them on the list
> because you never know if their ->lru field is going to be used for something
> else.
>
> Why would you want to ever do something like that though? I don't think you
> should use this name "just in case", unless you have some really good
> potential usage in mind.
>
> ---
> SUSE Labs, Novell Inc.
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

The name "Wired" could be changed to which one most kids think better
fits the job.

I choosed "Wired" for:
"Locked" will conflict with PG_locked bit of a pags.
"Pinned" indicates a short-term lock,so not fits the job too.

Shaoping Wang

2006/3/21, Nick Piggin <nickpiggin@yahoo.com.au>:
> Stone Wang wrote:
> > The list potentially could have more wider use.
> >
> > For example, kernel-space locked/pinned pages could be placed on the list too
> > (while mlocked pages are locked/pinned by system calls from user-space).
> >
>
> kernel-space pages are always pinned. And no, you can't put them on the list
> because you never know if their ->lru field is going to be used for something
> else.
>
> Why would you want to ever do something like that though? I don't think you
> should use this name "just in case", unless you have some really good
> potential usage in mind.
>
> ---
> SUSE Labs, Novell Inc.
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> The name "Wired" could be changed to which one most kids think better
> fits the job.
> 
> I choosed "Wired" for:
> "Locked" will conflict with PG_locked bit of a pags.
> "Pinned" indicates a short-term lock,so not fits the job too.
> 

Err we're going around in circles here. This tangent started because
I suggested that you could call them "mlock" or "mlocked".

But don't get too hung up on the naming. I pointed out quite a lot
of much more fundamental problems.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Stone Wang wrote:
> The name "Wired" could be changed to which one most kids think better
> fits the job.
> 
> I choosed "Wired" for:
> "Locked" will conflict with PG_locked bit of a pags.
> "Pinned" indicates a short-term lock,so not fits the job too.
> 

Err we're going around in circles here. This tangent started because
I suggested that you could call them "mlock" or "mlocked".

But don't get too hung up on the naming. I pointed out quite a lot
of much more fundamental problems.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Arjan van de Ven]

On Wed, 2006-03-22 at 00:37 -0500, Stone Wang wrote:
> The name "Wired" could be changed to which one most kids think better
> fits the job.
> 
> I choosed "Wired" for:
> "Locked" will conflict with PG_locked bit of a pags.
> "Pinned" indicates a short-term lock,so not fits the job too.

pinned does not imply short term

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Arjan van de Ven]

On Wed, 2006-03-22 at 00:37 -0500, Stone Wang wrote:
> The name "Wired" could be changed to which one most kids think better
> fits the job.
> 
> I choosed "Wired" for:
> "Locked" will conflict with PG_locked bit of a pags.
> "Pinned" indicates a short-term lock,so not fits the job too.

pinned does not imply short term

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Rik van Riel]

On Wed, 22 Mar 2006, Nick Piggin wrote:

> Why would you want to ever do something like that though? I don't think 
> you should use this name "just in case", unless you have some really 
> good potential usage in mind.

ramfs

-- 
All Rights Reversed

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Rik van Riel]

On Wed, 22 Mar 2006, Nick Piggin wrote:

> Why would you want to ever do something like that though? I don't think 
> you should use this name "just in case", unless you have some really 
> good potential usage in mind.

ramfs

-- 
All Rights Reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Rik van Riel wrote:
> On Wed, 22 Mar 2006, Nick Piggin wrote:
> 
> 
>>Why would you want to ever do something like that though? I don't think 
>>you should use this name "just in case", unless you have some really 
>>good potential usage in mind.
> 
> 
> ramfs
> 

Why would ramfs want its pages in this wired list? (I'm not so
familiar with it but I can't think of a reason).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Rik van Riel wrote:
> On Wed, 22 Mar 2006, Nick Piggin wrote:
> 
> 
>>Why would you want to ever do something like that though? I don't think 
>>you should use this name "just in case", unless you have some really 
>>good potential usage in mind.
> 
> 
> ramfs
> 

Why would ramfs want its pages in this wired list? (I'm not so
familiar with it but I can't think of a reason).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Rik van Riel]

On Sat, 25 Mar 2006, Nick Piggin wrote:
> Rik van Riel wrote:
> > On Wed, 22 Mar 2006, Nick Piggin wrote:
> > 
> > > Why would you want to ever do something like that though? I don't think
> > > you should use this name "just in case", unless you have some really good
> > > potential usage in mind.
> > 
> > ramfs
> 
> Why would ramfs want its pages in this wired list? (I'm not so
> familiar with it but I can't think of a reason).

Because ramfs pages cannot be paged out, which makes them locked
into memory the same way mlocked pages are.

-- 
All Rights Reversed

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Rik van Riel]

On Sat, 25 Mar 2006, Nick Piggin wrote:
> Rik van Riel wrote:
> > On Wed, 22 Mar 2006, Nick Piggin wrote:
> > 
> > > Why would you want to ever do something like that though? I don't think
> > > you should use this name "just in case", unless you have some really good
> > > potential usage in mind.
> > 
> > ramfs
> 
> Why would ramfs want its pages in this wired list? (I'm not so
> familiar with it but I can't think of a reason).

Because ramfs pages cannot be paged out, which makes them locked
into memory the same way mlocked pages are.

-- 
All Rights Reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Rik van Riel wrote:
> On Sat, 25 Mar 2006, Nick Piggin wrote:
> 
>>Rik van Riel wrote:
>>
>>>On Wed, 22 Mar 2006, Nick Piggin wrote:
>>>
>>>
>>>>Why would you want to ever do something like that though? I don't think
>>>>you should use this name "just in case", unless you have some really good
>>>>potential usage in mind.
>>>
>>>ramfs
>>
>>Why would ramfs want its pages in this wired list? (I'm not so
>>familiar with it but I can't think of a reason).
> 
> 
> Because ramfs pages cannot be paged out, which makes them locked
> into memory the same way mlocked pages are.
> 

I don't understand why they need to be on any list though,
that isn't an internal ramfs specific structure (ie. not
the just-in-case wired list).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Nick Piggin]

Rik van Riel wrote:
> On Sat, 25 Mar 2006, Nick Piggin wrote:
> 
>>Rik van Riel wrote:
>>
>>>On Wed, 22 Mar 2006, Nick Piggin wrote:
>>>
>>>
>>>>Why would you want to ever do something like that though? I don't think
>>>>you should use this name "just in case", unless you have some really good
>>>>potential usage in mind.
>>>
>>>ramfs
>>
>>Why would ramfs want its pages in this wired list? (I'm not so
>>familiar with it but I can't think of a reason).
> 
> 
> Because ramfs pages cannot be paged out, which makes them locked
> into memory the same way mlocked pages are.
> 

I don't understand why they need to be on any list though,
that isn't an internal ramfs specific structure (ie. not
the just-in-case wired list).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Dave Hansen]

On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> --- linux-2.6.15.orig/include/linux/mm.h        2006-01-02 22:21:10.000000000 -0500
> +++ linux-2.6.15/include/linux/mm.h     2006-03-07 01:49:12.000000000 -0500
> @@ -218,6 +221,10 @@
>         unsigned long flags;            /* Atomic flags, some possibly
>                                          * updated asynchronously */
>         atomic_t _count;                /* Usage count, see below. */
> +       unsigned short wired_count; /* Count of wirings of the page.
> +                                        * If not zero,the page would be SetPageWired,
> +                                        * and put on Wired list of the zone.
> +                                        */
>         atomic_t _mapcount;             /* Count of ptes mapped in mms,
>                                          * to show when page is mapped
>                                          * & limit reverse map searches. 

We're usually pretty picky about adding stuff to 'struct page'.  It
_just_ fits inside a cacheline on most 32-bit architectures.  

Can this wired_count not be derived at runtime?  It seems like it would
be possible to run through all VMAs mapping the page, and determining
how many of them are VM_LOCKED.  Would that be too slow?

Also, does it matter how many times it is locked, or just that
_somebody_ has it locked?  

-- Dave

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Dave Hansen]

On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> --- linux-2.6.15.orig/include/linux/mm.h        2006-01-02 22:21:10.000000000 -0500
> +++ linux-2.6.15/include/linux/mm.h     2006-03-07 01:49:12.000000000 -0500
> @@ -218,6 +221,10 @@
>         unsigned long flags;            /* Atomic flags, some possibly
>                                          * updated asynchronously */
>         atomic_t _count;                /* Usage count, see below. */
> +       unsigned short wired_count; /* Count of wirings of the page.
> +                                        * If not zero,the page would be SetPageWired,
> +                                        * and put on Wired list of the zone.
> +                                        */
>         atomic_t _mapcount;             /* Count of ptes mapped in mms,
>                                          * to show when page is mapped
>                                          * & limit reverse map searches. 

We're usually pretty picky about adding stuff to 'struct page'.  It
_just_ fits inside a cacheline on most 32-bit architectures.  

Can this wired_count not be derived at runtime?  It seems like it would
be possible to run through all VMAs mapping the page, and determining
how many of them are VM_LOCKED.  Would that be too slow?

Also, does it matter how many times it is locked, or just that
_somebody_ has it locked?  

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

2006/3/21, Dave Hansen <haveblue@us.ibm.com>:
> On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> > --- linux-2.6.15.orig/include/linux/mm.h        2006-01-02 22:21:10.000000000 -0500
> > +++ linux-2.6.15/include/linux/mm.h     2006-03-07 01:49:12.000000000 -0500
> > @@ -218,6 +221,10 @@
> >         unsigned long flags;            /* Atomic flags, some possibly
> >                                          * updated asynchronously */
> >         atomic_t _count;                /* Usage count, see below. */
> > +       unsigned short wired_count; /* Count of wirings of the page.
> > +                                        * If not zero,the page would be SetPageWired,
> > +                                        * and put on Wired list of the zone.
> > +                                        */
> >         atomic_t _mapcount;             /* Count of ptes mapped in mms,
> >                                          * to show when page is mapped
> >                                          * & limit reverse map searches.
>
> We're usually pretty picky about adding stuff to 'struct page'.  It
> _just_ fits inside a cacheline on most 32-bit architectures.
>
> Can this wired_count not be derived at runtime?  It seems like it would
> be possible to run through all VMAs mapping the page, and determining
> how many of them are VM_LOCKED.  Would that be too slow?

It can be derived, but perhaps would made code not that clear.

I will try accroding to your comments, and i think there could be
fast scanning of the vma list for this purpose.

> Also, does it matter how many times it is locked, or just that
> _somebody_ has it locked?

For now, it just matters somebody has it locked.
When munlock a page, it matters  somebody else has it locked.

>
> -- Dave
>
>

Re: [PATCH][5/8] proc: export mlocked pages info through "/proc/meminfo: Wired"

[Stone Wang]

2006/3/21, Dave Hansen <haveblue@us.ibm.com>:
> On Mon, 2006-03-20 at 08:37 -0500, Stone Wang wrote:
> > --- linux-2.6.15.orig/include/linux/mm.h        2006-01-02 22:21:10.000000000 -0500
> > +++ linux-2.6.15/include/linux/mm.h     2006-03-07 01:49:12.000000000 -0500
> > @@ -218,6 +221,10 @@
> >         unsigned long flags;            /* Atomic flags, some possibly
> >                                          * updated asynchronously */
> >         atomic_t _count;                /* Usage count, see below. */
> > +       unsigned short wired_count; /* Count of wirings of the page.
> > +                                        * If not zero,the page would be SetPageWired,
> > +                                        * and put on Wired list of the zone.
> > +                                        */
> >         atomic_t _mapcount;             /* Count of ptes mapped in mms,
> >                                          * to show when page is mapped
> >                                          * & limit reverse map searches.
>
> We're usually pretty picky about adding stuff to 'struct page'.  It
> _just_ fits inside a cacheline on most 32-bit architectures.
>
> Can this wired_count not be derived at runtime?  It seems like it would
> be possible to run through all VMAs mapping the page, and determining
> how many of them are VM_LOCKED.  Would that be too slow?

It can be derived, but perhaps would made code not that clear.

I will try accroding to your comments, and i think there could be
fast scanning of the vma list for this purpose.

> Also, does it matter how many times it is locked, or just that
> _somebody_ has it locked?

For now, it just matters somebody has it locked.
When munlock a page, it matters  somebody else has it locked.

>
> -- Dave
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>