linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] add buddyinfo /proc entry
@ 2002-08-16  2:31 Dave Hansen
  2002-08-16  4:31 ` Greg KH
  2002-08-16 14:31 ` Andrew Morton
  0 siblings, 2 replies; 11+ messages in thread
From: Dave Hansen @ 2002-08-16  2:31 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm, Martin J. Bligh

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Not _another_ proc entry!

The following patch originally by Martin Bligh exports some 
information about the buddy allocator.

Each column of numbers represents the number of pages of that order 
which are available.  In this case, there are 5 chunks of 
2^2*PAGE_SIZE available in ZONE_DMA, and 101 chunks of 2^4*PAGE_SIZE 
availble in ZONE_NORMAL, etc...  This information can give you a good 
idea about how fragmented memory is and give you a clue as to how big 
of an area you can safely allocate.

Node 0, zone      DMA      0      4      5      4      4      3 ...
Node 0, zone   Normal      1      0      0      1    101      8 ...
Node 0, zone  HighMem      2      0      0      1      1      0 ...

-- 
Dave Hansen
haveblue@us.ibm.com

[-- Attachment #2: buddyinfo-2.5.31+bk-0.patch --]
[-- Type: text/plain, Size: 3510 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.549   -> 1.550  
#	     mm/page_alloc.c	1.88    -> 1.89   
#	 fs/proc/proc_misc.c	1.34    -> 1.35   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/08/15	haveblue@nighthawk.sr71.net	1.550
# This small patch creates /proc/buddyinfo, which
# shows how many of each order page groups are available.
# 
# Port from -aa.
# --------------------------------------------
#
diff -Nru a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c
--- a/fs/proc/proc_misc.c	Thu Aug 15 14:56:23 2002
+++ b/fs/proc/proc_misc.c	Thu Aug 15 14:56:23 2002
@@ -190,6 +190,20 @@
 #undef K
 }
 
+extern struct seq_operations fragmentation_op;
+static int fragmentation_open(struct inode *inode, struct file *file)
+{
+	(void)inode;
+	return seq_open(file, &fragmentation_op);
+}
+
+static struct file_operations fragmentation_file_operations = {
+	open:		fragmentation_open,
+	read:		seq_read,
+	llseek:		seq_lseek,
+	release:	seq_release,
+};
+
 static int version_read_proc(char *page, char **start, off_t off,
 				 int count, int *eof, void *data)
 {
@@ -606,6 +620,7 @@
 	create_seq_entry("partitions", 0, &proc_partitions_operations);
 	create_seq_entry("interrupts", 0, &proc_interrupts_operations);
 	create_seq_entry("slabinfo",S_IWUSR|S_IRUGO,&proc_slabinfo_operations);
+	create_seq_entry("buddyinfo",S_IRUGO, &fragmentation_file_operations);
 #ifdef CONFIG_MODULES
 	create_seq_entry("modules", 0, &proc_modules_operations);
 	create_seq_entry("ksyms", 0, &proc_ksyms_operations);
diff -Nru a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c	Thu Aug 15 14:56:23 2002
+++ b/mm/page_alloc.c	Thu Aug 15 14:56:23 2002
@@ -924,3 +924,74 @@
 }
 
 __setup("memfrac=", setup_mem_frac);
+
+#ifdef CONFIG_PROC_FS
+
+#include <linux/seq_file.h>
+
+static void *frag_start(struct seq_file *m, loff_t *pos)
+{
+	pg_data_t *pgdat;
+	loff_t node = *pos;
+
+	(void)m;
+
+	for (pgdat = pgdat_list; pgdat && node; pgdat = pgdat->pgdat_next)
+		--node;
+
+	return pgdat;
+}
+
+static void *frag_next(struct seq_file *m, void *arg, loff_t *pos)
+{
+	pg_data_t *pgdat = (pg_data_t *)arg;
+
+	(void)m;
+	(*pos)++;
+	return pgdat->pgdat_next;
+}
+
+static void frag_stop(struct seq_file *m, void *arg)
+{
+	(void)m;
+	(void)arg;
+}
+
+/* 
+ * This walks the freelist for each zone. Whilst this is slow, I'd rather 
+ * be slow here than slow down the fast path by keeping stats - mjbligh
+ */
+static int frag_show(struct seq_file *m, void *arg)
+{
+	pg_data_t *pgdat = (pg_data_t *)arg;
+	zone_t *zone, *node_zones = pgdat->node_zones;
+	unsigned long flags;
+	int order;
+
+	for (zone = node_zones; zone - node_zones < MAX_NR_ZONES; ++zone) {
+		if (!zone->size)
+			continue;
+
+		spin_lock_irqsave(&zone->lock, flags);
+		seq_printf(m, "Node %d, zone %8s ", pgdat->node_id, zone->name);
+		for (order = 0; order < MAX_ORDER; ++order) {
+			unsigned long nr_bufs = 0;
+			list_t *elem;
+			list_for_each(elem, &zone->free_area[order].free_list)
+				++nr_bufs;
+			seq_printf(m, "%6lu ", nr_bufs);
+		}
+		spin_unlock_irqrestore(&zone->lock, flags);
+		seq_putc(m, '\n');
+	}
+	return 0;
+}
+
+struct seq_operations fragmentation_op = {
+	start:	frag_start,
+	next:	frag_next,
+	stop:	frag_stop,
+	show:	frag_show,
+};
+
+#endif /* CONFIG_PROC_FS */

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16  2:31 [PATCH] add buddyinfo /proc entry Dave Hansen
@ 2002-08-16  4:31 ` Greg KH
  2002-08-16  8:51   ` Dave Hansen
  2002-08-16 14:31 ` Andrew Morton
  1 sibling, 1 reply; 11+ messages in thread
From: Greg KH @ 2002-08-16  4:31 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Andrew Morton, linux-kernel, linux-mm, Martin J. Bligh

On Thu, Aug 15, 2002 at 07:31:44PM -0700, Dave Hansen wrote:
> Not _another_ proc entry!

Yes, not another one.  Why not move these to driverfs, where they
belong.

(ignore the driverfs name, it should be called kfs, or some such thing,
as stuff more than driver info should go there, just like these entries.)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16  4:31 ` Greg KH
@ 2002-08-16  8:51   ` Dave Hansen
  2002-08-16 14:39     ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Dave Hansen @ 2002-08-16  8:51 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, Martin J. Bligh

Greg KH wrote:
 > On Thu, Aug 15, 2002 at 07:31:44PM -0700, Dave Hansen wrote:
 >
 >> Not _another_ proc entry!
 >
 > Yes, not another one.  Why not move these to driverfs, where they
 > belong.

Could you show us how this particular situation might be laid out in a 
driverfs/kfs/gregfs tree?

It's great that you keep suggesting this, but we have another 
chicken-and-egg problem.

<SOAPBOX>
The problem with driverfs today is that it isn't worth it for _me_ to
use it to just get this one, single thing.  If I used driverfs right 
now, the only thing that I would get out of it would be ... buddyinfo! 
How is it worth my while to use it on a shared machine where most 
people probably won't be mounting driverfs, or _want_ it mounted as 
the default?
</SOAPBOX>

 > (ignore the driverfs name, it should be called kfs, or some such
 > thing, as stuff more than driver info should go there, just like
 > these entries.)

If even its most ardent supporters don't like its name...

-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16  2:31 [PATCH] add buddyinfo /proc entry Dave Hansen
  2002-08-16  4:31 ` Greg KH
@ 2002-08-16 14:31 ` Andrew Morton
  2002-08-16 21:03   ` William Lee Irwin III
  1 sibling, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2002-08-16 14:31 UTC (permalink / raw)
  To: Dave Hansen; +Cc: linux-kernel, linux-mm, Martin J. Bligh

Dave Hansen wrote:
> 
> ..
> +static void frag_stop(struct seq_file *m, void *arg)
> +{
> +       (void)m;
> +       (void)arg;
> +}

Don't tell me the compiler warns about this now?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16  8:51   ` Dave Hansen
@ 2002-08-16 14:39     ` Greg KH
  2002-08-16 16:19       ` Dave Hansen
  2002-08-19  0:04       ` Rusty Russell
  0 siblings, 2 replies; 11+ messages in thread
From: Greg KH @ 2002-08-16 14:39 UTC (permalink / raw)
  To: Dave Hansen; +Cc: linux-kernel, Martin J. Bligh

On Fri, Aug 16, 2002 at 01:51:08AM -0700, Dave Hansen wrote:
> Greg KH wrote:
> > On Thu, Aug 15, 2002 at 07:31:44PM -0700, Dave Hansen wrote:
> >
> >> Not _another_ proc entry!
> >
> > Yes, not another one.  Why not move these to driverfs, where they
> > belong.
> 
> Could you show us how this particular situation might be laid out in a 
> driverfs/kfs/gregfs tree?

root/vm/buddyinfo   ?

Ah, a gregfs, making up the components that describe me...that's going
to be a pretty ugly looking fs...

> It's great that you keep suggesting this, but we have another 
> chicken-and-egg problem.
> 
> <SOAPBOX>
> The problem with driverfs today is that it isn't worth it for _me_ to
> use it to just get this one, single thing.  If I used driverfs right 
> now, the only thing that I would get out of it would be ... buddyinfo! 
> How is it worth my while to use it on a shared machine where most 
> people probably won't be mounting driverfs, or _want_ it mounted as 
> the default?
> </SOAPBOX>

All it takes is one line added to /etc/fstab mounting driverfs at /sys.
As the code is not a .config option, you are using it if you mount it or
not :)  The fact that no one else will look at that mount point,
shouldn't matter to you.

And yes, for just one thing (hey, why don't you move _all_ the vm stats
over to it), it is worth adding that one line.  And you'll eventually
have to do it anyway, as these things _will_ be moving there.

Hell, tell me which machine you are using, and I'll go add it.

> > (ignore the driverfs name, it should be called kfs, or some such
> > thing, as stuff more than driver info should go there, just like
> > these entries.)
> 
> If even its most ardent supporters don't like its name...

I don't have to like the name to like what it does, and is used for,
right?

thanks,

greg k-h

> 
> -- 
> Dave Hansen
> haveblue@us.ibm.com
> 
> -
> 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/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 14:39     ` Greg KH
@ 2002-08-16 16:19       ` Dave Hansen
  2002-08-16 16:37         ` Greg KH
  2002-08-16 19:03         ` Patrick Mochel
  2002-08-19  0:04       ` Rusty Russell
  1 sibling, 2 replies; 11+ messages in thread
From: Dave Hansen @ 2002-08-16 16:19 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, Martin J. Bligh

Greg KH wrote:
> All it takes is one line added to /etc/fstab mounting driverfs at /sys.
> As the code is not a .config option, you are using it if you mount it or
> not :)  The fact that no one else will look at that mount point,
> shouldn't matter to you.
> 
> And yes, for just one thing (hey, why don't you move _all_ the vm stats
> over to it), it is worth adding that one line.  And you'll eventually
> have to do it anyway, as these things _will_ be moving there.
> 
> Hell, tell me which machine you are using, and I'll go add it.

How long has it been in the tree (2.4 and 2.5)?  I'll add it to my 
machine, but I am anticipating a 3 hour conversation as I explain to 
the other users why they got dropped to a root prompt because driverfs 
isn't supported when they boot.

-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 16:19       ` Dave Hansen
@ 2002-08-16 16:37         ` Greg KH
  2002-08-16 19:03         ` Patrick Mochel
  1 sibling, 0 replies; 11+ messages in thread
From: Greg KH @ 2002-08-16 16:37 UTC (permalink / raw)
  To: Dave Hansen; +Cc: linux-kernel, Martin J. Bligh

On Fri, Aug 16, 2002 at 09:19:10AM -0700, Dave Hansen wrote:
> 
> How long has it been in the tree (2.4 and 2.5)?

2.5

> I'll add it to my machine, but I am anticipating a 3 hour conversation
> as I explain to the other users why they got dropped to a root prompt
> because driverfs isn't supported when they boot.

???  My machines don't do that, they just complain and then continue on
with the boot sequence.

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 16:19       ` Dave Hansen
  2002-08-16 16:37         ` Greg KH
@ 2002-08-16 19:03         ` Patrick Mochel
  2002-08-16 21:04           ` Dave Hansen
  1 sibling, 1 reply; 11+ messages in thread
From: Patrick Mochel @ 2002-08-16 19:03 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Greg KH, linux-kernel, Martin J. Bligh


On Fri, 16 Aug 2002, Dave Hansen wrote:

> Greg KH wrote:
> > All it takes is one line added to /etc/fstab mounting driverfs at /sys.
> > As the code is not a .config option, you are using it if you mount it or
> > not :)  The fact that no one else will look at that mount point,
> > shouldn't matter to you.
> > 
> > And yes, for just one thing (hey, why don't you move _all_ the vm stats
> > over to it), it is worth adding that one line.  And you'll eventually
> > have to do it anyway, as these things _will_ be moving there.
> > 
> > Hell, tell me which machine you are using, and I'll go add it.
> 
> How long has it been in the tree (2.4 and 2.5)?  I'll add it to my 
> machine, but I am anticipating a 3 hour conversation as I explain to 
> the other users why they got dropped to a root prompt because driverfs 
> isn't supported when they boot.

You're making things up and spreading FUD. Why would you want to do that? 

Oh right, it's because most "kernel developers" would rather bitch about 
that which they do not understand and cut down other developers than suck 
it up and actually try to learn something from someone else. 

Get over it.


	-pat


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 14:31 ` Andrew Morton
@ 2002-08-16 21:03   ` William Lee Irwin III
  0 siblings, 0 replies; 11+ messages in thread
From: William Lee Irwin III @ 2002-08-16 21:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Dave Hansen, linux-kernel, linux-mm, Martin J. Bligh

Dave Hansen wrote:
+static void frag_stop(struct seq_file *m, void *arg)
+{
+       (void)m;
+       (void)arg;
+}

On Fri, Aug 16, 2002 at 07:31:33AM -0700, Andrew Morton wrote:
> Don't tell me the compiler warns about this now?

Woops -- that's actually a wli dropping. Some (?) of my code was
borrowed for this. Someone pounded -Werror into my head too hard
at school or something.


Cheers,
Bill

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 19:03         ` Patrick Mochel
@ 2002-08-16 21:04           ` Dave Hansen
  0 siblings, 0 replies; 11+ messages in thread
From: Dave Hansen @ 2002-08-16 21:04 UTC (permalink / raw)
  To: Patrick Mochel; +Cc: Greg KH, linux-kernel, Martin J. Bligh

Patrick Mochel wrote:
> You're making things up and spreading FUD. Why would you want to do that? 

Because IBM has a grand, secret plan to replace driverfs with 
BigBlueFS.  We have brainwashed Linus into taking it and we will rule 
the world!

No, I'm just being selfish and I'm a bit uninformed.  I understand it 
better now because Greg explained why you want to do it.  The thing 
that did it for me was Linus's decree that vm tunables _will_ move to 
driverfs.  That changes the scenario from "Greg and Patrick are 
bitching" to "Linus wants this" and thus it will be the wave of the 
future.   Maybe you guys need to make this a bit more clear.

> Oh right, it's because most "kernel developers" would rather bitch about 
> that which they do not understand and cut down other developers than suck 
> it up and actually try to learn something from someone else. 

I'm trying to understand, that's why I asked so many questions.  I am 
mistaken about the machine not booting completely if it doesn't 
understand a fs-type, Greg corrected me here.

Summary:
A driverfs version of this patch is on the way.
-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add buddyinfo /proc entry
  2002-08-16 14:39     ` Greg KH
  2002-08-16 16:19       ` Dave Hansen
@ 2002-08-19  0:04       ` Rusty Russell
  1 sibling, 0 replies; 11+ messages in thread
From: Rusty Russell @ 2002-08-19  0:04 UTC (permalink / raw)
  To: Greg KH; +Cc: haveblue, linux-kernel, Martin.Bligh

On Fri, 16 Aug 2002 07:39:25 -0700
Greg KH <greg@kroah.com> wrote:

> On Fri, Aug 16, 2002 at 01:51:08AM -0700, Dave Hansen wrote:
> > Greg KH wrote:
> > > On Thu, Aug 15, 2002 at 07:31:44PM -0700, Dave Hansen wrote:
> > >
> > >> Not _another_ proc entry!
> > >
> > > Yes, not another one.  Why not move these to driverfs, where they
> > > belong.
> > 
> > Could you show us how this particular situation might be laid out in a 
> > driverfs/kfs/gregfs tree?
> 
> root/vm/buddyinfo   ?

root/memory please.  vm is a little obscure.

Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2002-08-19  0:25 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-16  2:31 [PATCH] add buddyinfo /proc entry Dave Hansen
2002-08-16  4:31 ` Greg KH
2002-08-16  8:51   ` Dave Hansen
2002-08-16 14:39     ` Greg KH
2002-08-16 16:19       ` Dave Hansen
2002-08-16 16:37         ` Greg KH
2002-08-16 19:03         ` Patrick Mochel
2002-08-16 21:04           ` Dave Hansen
2002-08-19  0:04       ` Rusty Russell
2002-08-16 14:31 ` Andrew Morton
2002-08-16 21:03   ` William Lee Irwin III

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).