Re: Why no bigphysarea in mainline?
On Fri, 18 Mar 2005 01:35, Dave Hansen wrote: > Doing mem= for drivers isn't just a hack, it's *WRONG*. It's a ticking > time bomb that magically happens to work on some systems. It will not > work consistently on a discontiguous memory system, or a memory hotplug > system. I couldn't agree more. Problem is I've been asked to change the way mem=X works on PPC64 so that this hack will work, which is a horrible thought. > Could you give some examples of drivers which are in the kernel that > could benefit from this patch? We don't tend to put things like this > in, unless they have actual users. We don't tend to change code for > out-of-tree users, either. No I can't. I've been approached by several "vendors" asking about using mem=X hacks on PPC64, however I doubt any of them have code in-tree. I'll check though. cheers pgpoVUl47Rs9y.pgp Description: PGP signature
Re: Why no bigphysarea in mainline?
On Thu, 2005-03-17 at 20:57 +1100, Michael Ellerman wrote: > I realise bigphysarea is a bit of a hack, but it's no where near as > big a hack as using mem=X to limit the kernel's memory and then using > the rest of memory for your device driver. Well, the fact that you can get away with that is a coincidence. What if you have 4GB of RAM on an x86 machine, you do mem=3G, and you start using that top GB of memory for your driver? You eventually write into the PCI config space. Ooops. You get strange errors that way. Doing mem= for drivers isn't just a hack, it's *WRONG*. It's a ticking time bomb that magically happens to work on some systems. It will not work consistently on a discontiguous memory system, or a memory hotplug system. > If no one has any fundamental objections I think it'd be good to get > this merged into mainline so people start using it rather than mem=X > hacks. To that end please let me know what you think is wrong with > the patch as it stands (below). Could you give some examples of drivers which are in the kernel that could benefit from this patch? We don't tend to put things like this in, unless they have actual users. We don't tend to change code for out-of-tree users, either. -- Dave - 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/
Why no bigphysarea in mainline?
Hi all,
Can anyone recall if there's ever been a discussion about merging the
bigphysarea patch (see below) into mainline? I couldn't find much of
interest on google.
I realise bigphysarea is a bit of a hack, but it's no where near as
big a hack as using mem=X to limit the kernel's memory and then using
the rest of memory for your device driver.
The reason I'm curious is because I've gotten several queries about the
mem=X option on PPC64 and whether it will support this hack, which it
won't.
If no one has any fundamental objections I think it'd be good to get
this merged into mainline so people start using it rather than mem=X
hacks. To that end please let me know what you think is wrong with
the patch as it stands (below).
cheers
Nick Martin's version for 2.6.9 (which applies to 2.6.11):
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/2076.html
And the guts of it:
Index: 2.6.11-bigphysarea/mm/bigphysarea.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ 2.6.11-bigphysarea/mm/bigphysarea.c 2005-03-17 19:15:08.256421832 +1100
@@ -0,0 +1,353 @@
+/* linux/mm/bigphysarea.c, M. Welsh ([EMAIL PROTECTED])
+ * Copyright (c) 1996 by Matt Welsh.
+ * Extended by Roger Butenuth ([EMAIL PROTECTED]), October 1997
+ * Extended for linux-2.1.121 till 2.4.0 (June 2000)
+ * by Pauline Middelink <[EMAIL PROTECTED]>
+ * Extended for linux-2.6.9 (November 2004)
+ * by Nick Martin <[EMAIL PROTECTED]>
+ *
+ * This is a set of routines which allow you to reserve a large (?)
+ * amount of physical memory at boot-time, which can be allocated/deallocated
+ * by drivers. This memory is intended to be used for devices such as
+ * video framegrabbers which need a lot of physical RAM (above the amount
+ * allocated by kmalloc). This is by no means efficient or recommended;
+ * to be used only in extreme circumstances.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int get_info(char* buf, char**, off_t, int);
+
+typedef struct range_struct {
+ struct range_struct *next;
+ caddr_t base; /* base of allocated block */
+ size_t size; /* size in bytes */
+} range_t;
+
+/*
+ * 0: nothing initialized
+ * 1: bigphysarea_pages initialized
+ * 2: free list initialized
+ */
+static int init_level = 0;
+static int bigphysarea_pages = 0;
+static caddr_t bigphysarea = 0;
+static range_t *free_list = NULL;
+static range_t *used_list = NULL;
+static struct resource mem_resource = { "Bigphysarea", 0, 0,
IORESOURCE_MEM|IORESOURCE_BUSY };
+
+static
+int __init bigphysarea_init(void)
+{
+ if (bigphysarea_pages == 0 || bigphysarea == 0)
+ return -EINVAL;
+
+ /* create to /proc entry for it */
+ if (!create_proc_info_entry("bigphysarea",0444,NULL,get_info)) {
+ // ohoh, no way to free the allocated memory!
+ // continue without proc support, it not fatal in itself
+// free_bootmem((unsigned
long)bigphysarea>>PAGE_SHIFT,bigphysarea_pagesnext)
+ if ((*range_ptr)->base >= base)
+ break;
+ range->next = *range_ptr;
+ *range_ptr = range;
+ /*
+* Concatenate free range with neighbors, if possible.
+* Try for upper neighbor (next in list) first, then
+* for lower neighbor (predecessor in list).
+*/
+ if (range->next != NULL &&
+ range->base + range->size == range->next->base) {
+ next = range->next;
+ range->size += range->next->size;
+ range->next = next->next;
+ kfree(next);
+ }
+ if (prev != NULL &&
+ prev->base + prev->size == range->base) {
+ prev->size += prev->next->size;
+ prev->next = range->next;
+
Why no bigphysarea in mainline?
Hi all,
Can anyone recall if there's ever been a discussion about merging the
bigphysarea patch (see below) into mainline? I couldn't find much of
interest on google.
I realise bigphysarea is a bit of a hack, but it's no where near as
big a hack as using mem=X to limit the kernel's memory and then using
the rest of memory for your device driver.
The reason I'm curious is because I've gotten several queries about the
mem=X option on PPC64 and whether it will support this hack, which it
won't.
If no one has any fundamental objections I think it'd be good to get
this merged into mainline so people start using it rather than mem=X
hacks. To that end please let me know what you think is wrong with
the patch as it stands (below).
cheers
Nick Martin's version for 2.6.9 (which applies to 2.6.11):
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/2076.html
And the guts of it:
Index: 2.6.11-bigphysarea/mm/bigphysarea.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ 2.6.11-bigphysarea/mm/bigphysarea.c 2005-03-17 19:15:08.256421832 +1100
@@ -0,0 +1,353 @@
+/* linux/mm/bigphysarea.c, M. Welsh ([EMAIL PROTECTED])
+ * Copyright (c) 1996 by Matt Welsh.
+ * Extended by Roger Butenuth ([EMAIL PROTECTED]), October 1997
+ * Extended for linux-2.1.121 till 2.4.0 (June 2000)
+ * by Pauline Middelink [EMAIL PROTECTED]
+ * Extended for linux-2.6.9 (November 2004)
+ * by Nick Martin [EMAIL PROTECTED]
+ *
+ * This is a set of routines which allow you to reserve a large (?)
+ * amount of physical memory at boot-time, which can be allocated/deallocated
+ * by drivers. This memory is intended to be used for devices such as
+ * video framegrabbers which need a lot of physical RAM (above the amount
+ * allocated by kmalloc). This is by no means efficient or recommended;
+ * to be used only in extreme circumstances.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/config.h
+#include linux/ptrace.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/pci.h
+#include linux/proc_fs.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/bootmem.h
+#include linux/errno.h
+#include linux/bigphysarea.h
+
+static int get_info(char* buf, char**, off_t, int);
+
+typedef struct range_struct {
+ struct range_struct *next;
+ caddr_t base; /* base of allocated block */
+ size_t size; /* size in bytes */
+} range_t;
+
+/*
+ * 0: nothing initialized
+ * 1: bigphysarea_pages initialized
+ * 2: free list initialized
+ */
+static int init_level = 0;
+static int bigphysarea_pages = 0;
+static caddr_t bigphysarea = 0;
+static range_t *free_list = NULL;
+static range_t *used_list = NULL;
+static struct resource mem_resource = { Bigphysarea, 0, 0,
IORESOURCE_MEM|IORESOURCE_BUSY };
+
+static
+int __init bigphysarea_init(void)
+{
+ if (bigphysarea_pages == 0 || bigphysarea == 0)
+ return -EINVAL;
+
+ /* create to /proc entry for it */
+ if (!create_proc_info_entry(bigphysarea,0444,NULL,get_info)) {
+ // ohoh, no way to free the allocated memory!
+ // continue without proc support, it not fatal in itself
+// free_bootmem((unsigned
long)bigphysareaPAGE_SHIFT,bigphysarea_pagesPAGE_SHIFT);
+// bigphysarea = 0;
+// return -ENOMEM;
+ }
+
+ init_level = 1;
+
+ printk(KERN_INFO bigphysarea: Allocated %d pages at 0x%p.\n,
+ bigphysarea_pages, bigphysarea);
+
+ return 0;
+}
+
+__initcall(bigphysarea_init);
+
+/*
+ * call when 'bigphysarea=' is given on the commandline.
+ *
+ * Strangely, bootmem is still active during this call, but
+ * during the processing of the initcalls it isn't anymore!
+ * So we alloc the needed memory here instead of bigphysarea_init().
+ */
+static
+int __init bigphysarea_setup(char *str)
+{
+ int par;
+ if (get_option(str,par)) {
+ bigphysarea_pages = par;
+ // Alloc the memory
+ bigphysarea =
alloc_bootmem_low_pages(bigphysarea_pagesPAGE_SHIFT);
+ if (!bigphysarea) {
+ printk(KERN_CRIT bigphysarea: not enough memory for %d
Re: Why no bigphysarea in mainline?
On Thu, 2005-03-17 at 20:57 +1100, Michael Ellerman wrote: I realise bigphysarea is a bit of a hack, but it's no where near as big a hack as using mem=X to limit the kernel's memory and then using the rest of memory for your device driver. Well, the fact that you can get away with that is a coincidence. What if you have 4GB of RAM on an x86 machine, you do mem=3G, and you start using that top GB of memory for your driver? You eventually write into the PCI config space. Ooops. You get strange errors that way. Doing mem= for drivers isn't just a hack, it's *WRONG*. It's a ticking time bomb that magically happens to work on some systems. It will not work consistently on a discontiguous memory system, or a memory hotplug system. If no one has any fundamental objections I think it'd be good to get this merged into mainline so people start using it rather than mem=X hacks. To that end please let me know what you think is wrong with the patch as it stands (below). Could you give some examples of drivers which are in the kernel that could benefit from this patch? We don't tend to put things like this in, unless they have actual users. We don't tend to change code for out-of-tree users, either. -- Dave - 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/
Re: Why no bigphysarea in mainline?
On Fri, 18 Mar 2005 01:35, Dave Hansen wrote: Doing mem= for drivers isn't just a hack, it's *WRONG*. It's a ticking time bomb that magically happens to work on some systems. It will not work consistently on a discontiguous memory system, or a memory hotplug system. I couldn't agree more. Problem is I've been asked to change the way mem=X works on PPC64 so that this hack will work, which is a horrible thought. Could you give some examples of drivers which are in the kernel that could benefit from this patch? We don't tend to put things like this in, unless they have actual users. We don't tend to change code for out-of-tree users, either. No I can't. I've been approached by several vendors asking about using mem=X hacks on PPC64, however I doubt any of them have code in-tree. I'll check though. cheers pgpoVUl47Rs9y.pgp Description: PGP signature
