From: Randy Dunlap <randy.dunlap@oracle.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>
Subject: [PATCH -mmotm] vmstat: fix build errors when PROC_FS is disabled
Date: Thu, 15 Apr 2010 16:38:28 -0700 [thread overview]
Message-ID: <20100415163828.34f53758.randy.dunlap@oracle.com> (raw)
In-Reply-To: <201004152210.o3FMA7KV001909@imap1.linux-foundation.org>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix vmstat.c to build when CONFIG_PROC_FS is disabled
but CONFIG_DEBUG_FS is enabled.
Fixes around 25 errors.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Mel Gorman <mel@csn.ul.ie>
---
mm/vmstat.c | 119 ++++++++++++++++++++++++--------------------------
1 file changed, 59 insertions(+), 60 deletions(-)
--- mmotm-2010-0415-1442.orig/mm/vmstat.c
+++ mmotm-2010-0415-1442/mm/vmstat.c
@@ -16,6 +16,7 @@
#include <linux/cpu.h>
#include <linux/vmstat.h>
#include <linux/sched.h>
+#include <linux/seq_file.h>
#include <linux/math64.h>
#ifdef CONFIG_VM_EVENT_COUNTERS
@@ -380,18 +381,57 @@ void zone_statistics(struct zone *prefer
}
#endif
-#ifdef CONFIG_PROC_FS
-#include <linux/proc_fs.h>
-#include <linux/seq_file.h>
-
-static char * const migratetype_names[MIGRATE_TYPES] = {
- "Unmovable",
- "Reclaimable",
- "Movable",
- "Reserve",
- "Isolate",
+struct contig_page_info {
+ unsigned long free_pages;
+ unsigned long free_blocks_total;
+ unsigned long free_blocks_suitable;
};
+/* Walk all the zones in a node and print using a callback */
+static void walk_zones_in_node(struct seq_file *m, pg_data_t *pgdat,
+ void (*print)(struct seq_file *m, pg_data_t *, struct zone *))
+{
+ struct zone *zone;
+ struct zone *node_zones = pgdat->node_zones;
+ unsigned long flags;
+
+ for (zone = node_zones; zone - node_zones < MAX_NR_ZONES; ++zone) {
+ if (!populated_zone(zone))
+ continue;
+
+ spin_lock_irqsave(&zone->lock, flags);
+ print(m, pgdat, zone);
+ spin_unlock_irqrestore(&zone->lock, flags);
+ }
+}
+
+/*
+ * A fragmentation index only makes sense if an allocation of a requested
+ * size would fail. If that is true, the fragmentation index indicates
+ * whether external fragmentation or a lack of memory was the problem.
+ * The value can be used to determine if page reclaim or compaction
+ * should be used
+ */
+int __fragmentation_index(unsigned int order, struct contig_page_info *info)
+{
+ unsigned long requested = 1UL << order;
+
+ if (!info->free_blocks_total)
+ return 0;
+
+ /* Fragmentation index only makes sense when a request would fail */
+ if (info->free_blocks_suitable)
+ return -1000;
+
+ /*
+ * Index is between 0 and 1 so return within 3 decimal places
+ *
+ * 0 => allocation would fail due to lack of memory
+ * 1 => allocation would fail due to fragmentation
+ */
+ return 1000 - div_u64( (1000+(div_u64(info->free_pages * 1000ULL, requested))), info->free_blocks_total);
+}
+
static void *frag_start(struct seq_file *m, loff_t *pos)
{
pg_data_t *pgdat;
@@ -416,23 +456,16 @@ static void frag_stop(struct seq_file *m
{
}
-/* Walk all the zones in a node and print using a callback */
-static void walk_zones_in_node(struct seq_file *m, pg_data_t *pgdat,
- void (*print)(struct seq_file *m, pg_data_t *, struct zone *))
-{
- struct zone *zone;
- struct zone *node_zones = pgdat->node_zones;
- unsigned long flags;
-
- for (zone = node_zones; zone - node_zones < MAX_NR_ZONES; ++zone) {
- if (!populated_zone(zone))
- continue;
+#ifdef CONFIG_PROC_FS
+#include <linux/proc_fs.h>
- spin_lock_irqsave(&zone->lock, flags);
- print(m, pgdat, zone);
- spin_unlock_irqrestore(&zone->lock, flags);
- }
-}
+static char * const migratetype_names[MIGRATE_TYPES] = {
+ "Unmovable",
+ "Reclaimable",
+ "Movable",
+ "Reserve",
+ "Isolate",
+};
static void frag_show_print(struct seq_file *m, pg_data_t *pgdat,
struct zone *zone)
@@ -455,39 +488,6 @@ static int frag_show(struct seq_file *m,
return 0;
}
-struct contig_page_info {
- unsigned long free_pages;
- unsigned long free_blocks_total;
- unsigned long free_blocks_suitable;
-};
-
-/*
- * A fragmentation index only makes sense if an allocation of a requested
- * size would fail. If that is true, the fragmentation index indicates
- * whether external fragmentation or a lack of memory was the problem.
- * The value can be used to determine if page reclaim or compaction
- * should be used
- */
-int __fragmentation_index(unsigned int order, struct contig_page_info *info)
-{
- unsigned long requested = 1UL << order;
-
- if (!info->free_blocks_total)
- return 0;
-
- /* Fragmentation index only makes sense when a request would fail */
- if (info->free_blocks_suitable)
- return -1000;
-
- /*
- * Index is between 0 and 1 so return within 3 decimal places
- *
- * 0 => allocation would fail due to lack of memory
- * 1 => allocation would fail due to fragmentation
- */
- return 1000 - div_u64( (1000+(div_u64(info->free_pages * 1000ULL, requested))), info->free_blocks_total);
-}
-
static void pagetypeinfo_showfree_print(struct seq_file *m,
pg_data_t *pgdat, struct zone *zone)
{
@@ -1001,7 +1001,6 @@ module_init(setup_vmstat)
#ifdef CONFIG_DEBUG_FS
#include <linux/debugfs.h>
-#include <linux/seq_file.h>
static struct dentry *extfrag_debug_root;
next prev parent reply other threads:[~2010-04-15 23:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-15 21:42 mmotm 2010-04-15-14-42 uploaded akpm
2010-04-15 23:38 ` Randy Dunlap [this message]
2010-04-16 16:03 ` mmotm 2010-04-15-14-42 uploaded (shmem, CGROUP_MEM_RES_CTLR) Randy Dunlap
2010-04-19 1:49 ` Daisuke Nishimura
2010-04-19 2:17 ` Randy Dunlap
2010-04-19 10:01 ` error at compaction (Re: mmotm 2010-04-15-14-42 uploaded KAMEZAWA Hiroyuki
2010-04-19 18:14 ` Mel Gorman
2010-04-19 19:39 ` Mel Gorman
2010-04-20 2:30 ` KAMEZAWA Hiroyuki
2010-04-20 2:39 ` Minchan Kim
2010-04-20 3:07 ` KAMEZAWA Hiroyuki
2010-04-20 3:58 ` Minchan Kim
2010-04-20 4:24 ` KAMEZAWA Hiroyuki
2010-04-20 8:20 ` Mel Gorman
2010-04-20 8:32 ` Minchan Kim
2010-04-20 8:44 ` Mel Gorman
2010-04-20 9:50 ` Minchan Kim
2010-04-20 9:58 ` Mel Gorman
2010-04-20 10:14 ` Minchan Kim
2010-04-21 8:28 ` KAMEZAWA Hiroyuki
2010-04-21 9:48 ` KAMEZAWA Hiroyuki
2010-04-21 10:20 ` Mel Gorman
2010-04-21 16:52 ` Minchan Kim
2010-04-21 23:01 ` Minchan Kim
2010-04-20 2:35 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100415163828.34f53758.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).