1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

That incredibly useful patch for 2.4.X that Andrea wrote that splits the kernel user space 
into 1GB/2GB/3GB sections  I ported to 2.6.8.1 and posted it to:

ftp.kernel.org:/pub/linux/kernel/people/jmerkey/patches/linux-2.6.8.1-highmem-split-08-25-04.patch

I was not able to located a 2.6.8 version of this patch so I ported one.  I apologize in advance
if I replicated anyone elses work.

Using HIGHMEM (aka.  the extended Linux TLB reloading hits/second test) is not optimal for embedded systems and appliance versions of Linux we use so this is submitted.  I'll maintain
this patch (and keep it working) for folks who need it.

Would be nice to have in the kernel for appliance Linux.

** I CERTIFY THAT THIS CODE DOES NOT CONTAIN ANY INTELECTUAL PROPERTY 
OF ANYONE OTHER THAN THE ORIGINAL LINUX CONTRIBUTORS THE FILES
WERE DERIVED FROM. ***

Jeff V. Merkey

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

On Thu, Aug 26, 2004 at 04:21:48AM +0000, jmerkey@comcast.net wrote:
> That incredibly useful patch for 2.4.X that Andrea wrote that splits
> the kernel user space into 1GB/2GB/3GB sections  I ported to 2.6.8.1
> and posted it to:
> ftp.kernel.org:/pub/linux/kernel/people/jmerkey/patches/linux-2.6.8.1-highmem-split-08-25-04.patch
> I was not able to located a 2.6.8 version of this patch so I ported
> one.  I apologize in advance if I replicated anyone elses work.
> Using HIGHMEM (aka.  the extended Linux TLB reloading hits/second
> test) is not optimal for embedded systems and appliance versions of
> Linux we use so this is submitted.  I'll maintain this patch (and
> keep it working) for folks who need it.
> Would be nice to have in the kernel for appliance Linux.
> ** I CERTIFY THAT THIS CODE DOES NOT CONTAIN ANY INTELECTUAL PROPERTY 
> OF ANYONE OTHER THAN THE ORIGINAL LINUX CONTRIBUTORS THE FILES
> WERE DERIVED FROM. ***

ELF ABI violation. "...the reserved area shall not consume more than
1GB of the address space."


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Martin J. Bligh]

> That incredibly useful patch for 2.4.X that Andrea wrote that splits the kernel user space 
> into 1GB/2GB/3GB sections  I ported to 2.6.8.1 and posted it to:
> 
> ftp.kernel.org:/pub/linux/kernel/people/jmerkey/patches/linux-2.6.8.1-highmem-split-08-25-04.patch
> 
> I was not able to located a 2.6.8 version of this patch so I ported one.  I apologize in advance
> if I replicated anyone elses work.
> 
> Using HIGHMEM (aka.  the extended Linux TLB reloading hits/second test) is not optimal for embedded systems and appliance versions of Linux we use so this is submitted.  I'll maintain
> this patch (and keep it working) for folks who need it.
> 
> Would be nice to have in the kernel for appliance Linux.
> 
> ** I CERTIFY THAT THIS CODE DOES NOT CONTAIN ANY INTELECTUAL PROPERTY 
> OF ANYONE OTHER THAN THE ORIGINAL LINUX CONTRIBUTORS THE FILES
> WERE DERIVED FROM. ***

We've tried to get Linus to take that patch multiple times. He said no.

M.

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Roland Dreier]

    jmerkey> That incredibly useful patch for 2.4.X that Andrea wrote
    jmerkey> that splits the kernel user space into 1GB/2GB/3GB
    jmerkey> sections I ported to 2.6.8.1 and posted it to:

    jmerkey> ftp.kernel.org:/pub/linux/kernel/people/jmerkey/patches/linux-2.6.8.1-highmem-split-08-25-04.patch

This is indeed pretty useful.  A few comments on your version of the patch:

 - might as well post a patch this small inline
 - In Kconfig, what happens if someone turns on highmem?  It seems all
   the USER_XXX choices depend on NOHIGHMEM.  also, the config option
   probably needs at least some help text.
 - the change to vmlinux.ld.S can be dropped from future versions
   (Linus merged this post-2.6.8)
 - why create PAGE_OFFSET_RAW in asm-generic, when it depends on
   i386-only config symbols and is only used in i386?
 - what's the reason for the odd rewrite of free_one_pgd()? it looks
   equivalent (and misindented)

Thanks,
  Roland

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Roland Dreier]

    William> ELF ABI violation. "...the reserved area shall not
    William> consume more than 1GB of the address space."

Agreed, but I do like running with PAGE_OFFSET == 0xB0000000 on my
main box, which has 1 GB of RAM.  I can avoid highmem and still use
the last 128 MB of RAM.  It takes me about 3 seconds to edit
<asm/page.h> when I build a new kernel so I'm not arguing for merging
this, though.

 - R.

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

At some point in the past, I wrote:
William> ELF ABI violation. "...the reserved area shall not
William> consume more than 1GB of the address space."

On Wed, Aug 25, 2004 at 09:46:43PM -0700, Roland Dreier wrote:
> Agreed, but I do like running with PAGE_OFFSET == 0xB0000000 on my
> main box, which has 1 GB of RAM.  I can avoid highmem and still use
> the last 128 MB of RAM.  It takes me about 3 seconds to edit
> <asm/page.h> when I build a new kernel so I'm not arguing for merging
> this, though.

Though asinine, the ABI spec is set in stone.


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Ryan Cumming]

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

On Wednesday 25 August 2004 21:49, William Lee Irwin III wrote:
> At some point in the past, I wrote:
> William> ELF ABI violation. "...the reserved area shall not
> William> consume more than 1GB of the address space."
>
> On Wed, Aug 25, 2004 at 09:46:43PM -0700, Roland Dreier wrote:
> > Agreed, but I do like running with PAGE_OFFSET == 0xB0000000 on my
> > main box, which has 1 GB of RAM.  I can avoid highmem and still use
> > the last 128 MB of RAM.  It takes me about 3 seconds to edit
> > <asm/page.h> when I build a new kernel so I'm not arguing for merging
> > this, though.
>
> Though asinine, the ABI spec is set in stone.

And at least one app (valgrind) chokes with as little as 1.25G of reserved 
space.

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

Why should Linux, which supports multiple executable formats, tie itself to ELF exclusively?
I doubt I am going to need to run ORACLE or some other piggish app on my embedded
linux system, but I would like to have more kernel address space for drivers and other
appliance type features.  What do you plan to do when the driver base becomes as 
large as the one in WIndows 2000/XP and you don't have enough memory to load all 
the drivers.  Right now, iptables barfs even with 3GB of address space when you load up about a  dozen virtual network interfaces ?  Microsoft had this same problem (only at a much
sooner juncture in their platform evolution) and went to VM support in the kernel itself to increase virtual address space for kernel apps, file systems, and drivers when thye hit the 
wall.    It's coming time to start thinking about it.  

Jeff


> At some point in the past, I wrote:
> William> ELF ABI violation. "...the reserved area shall not
> William> consume more than 1GB of the address space."
> 
> On Wed, Aug 25, 2004 at 09:46:43PM -0700, Roland Dreier wrote:
> > Agreed, but I do like running with PAGE_OFFSET == 0xB0000000 on my
> > main box, which has 1 GB of RAM.  I can avoid highmem and still use
> > the last 128 MB of RAM.  It takes me about 3 seconds to edit
> > <asm/page.h> when I build a new kernel so I'm not arguing for merging
> > this, though.
> 
> Though asinine, the ABI spec is set in stone.
> 
> 
> -- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

At some point in the past, my attribution was stripped from:
>> Though asinine, the ABI spec is set in stone.

On Thu, Aug 26, 2004 at 08:24:38PM +0000, jmerkey@comcast.net wrote:
> Why should Linux, which supports multiple executable formats, tie
> itself to ELF exclusively? I doubt I am going to need to run ORACLE
> or some other piggish app on my embedded linux system, but I would
> like to have more kernel address space for drivers and other
> appliance type features.  What do you plan to do when the driver base
> becomes as large as the one in WIndows 2000/XP and you don't have
> enough memory to load all the drivers.  Right now, iptables barfs
> even with 3GB of address space when you load up about a  dozen
> virtual network interfaces ?  Microsoft had this same problem (only
> at a much sooner juncture in their platform evolution) and went to
> VM support in the kernel itself to increase virtual address space for
> kernel apps, file systems, and drivers when thye hit the wall. It's
> coming time to start thinking about it.  

You're years late to this game. It's been thought about and the
consensus (which I disagreed with) was to reject virtualspace pressure
related changes of this kind for 32-bit platforms in favor of refusing
to support 32-bit platforms and/or workloads requiring them.

Also, please line wrap at 80 characters (preferably 70) and please
don't top post. The request about "top posting" is that placing quoted
text prior to your responses in the message, with a line attributing the
quoted text to the original author immediately above the quoted text is
greatly preferred over the quoting arrangements made in your post(s).


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

> You're years late to this game. It's been thought about and the
> consensus (which I disagreed with) was to reject virtualspace pressure
> related changes of this kind for 32-bit platforms in favor of refusing
> to support 32-bit platforms and/or workloads requiring them.
> 

This has nothing to do with only having 1GB of kernel address 
space and not enough virtual space to load a large swath of drivers
or support modules loading reentrantly.  It's a little difficult to quantify
 how much kernel address space will be needed when you don't
know if a full configuration will fit into it.  The fact people use this 
patch at all is **EVIDENCE THAT THERE ALREADY IS A PROBLEM**
with limiting kernel address space to 1GB.  And who the hell cares about 
a mouldy, antiquated ABI spec modeled after 1970 Unix technology anyway?  It 
should be another option for executable formats.   All this ABI compatibility huey 
is some Intel/SCO pipe dream for supporting applications across multiple Unix 
platforms anyway.  If it doesn't run on Linux, who the hell cares?

:-)

Jeff

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Dave Jones]

On Thu, Aug 26, 2004 at 08:24:38PM +0000, jmerkey@comcast.net wrote:
 
 > What do you plan to do when the driver base becomes as 
 > large as the one in WIndows 2000/XP

There's a slew of drivers for ancient hardware in Linux that will /never/
be supported in Windows 2000/XP. Given we also support a majority of modern
hardware, chances are we're either comparable, or maybe even surpassing
Microsoft in terms of number of drivers shipped.

 > and you don't have enough memory to load all the drivers.

Since when do we load /all/ the drivers ? That would be silly.

 > Right now, iptables barfs even with 3GB of address space when you load up
 > about a dozen virtual network interfaces ?

I'll hazard a guess this has nothing whatsoever do to with address space sizes.

 > Microsoft had this same problem (only at a much sooner juncture in their
 > platform evolution) and went to VM support in the kernel
 > itself to increase virtual address space for kernel apps, file systems, and
 > drivers when thye hit the wall.    It's coming time to start thinking about
 > it.  

If we did stupid things like trying to load every single driver, maybe.
But we don't, so I think you're chasing ghosts.

		Dave

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

At some point in the past, my attribution was stripped from:
>> You're years late to this game. It's been thought about and the
>> consensus (which I disagreed with) was to reject virtualspace pressure
>> related changes of this kind for 32-bit platforms in favor of refusing
>> to support 32-bit platforms and/or workloads requiring them.

On Thu, Aug 26, 2004 at 09:08:19PM +0000, jmerkey@comcast.net wrote:
> This has nothing to do with only having 1GB of kernel address 
> space and not enough virtual space to load a large swath of drivers
> or support modules loading reentrantly.  It's a little difficult to
> quantify how much kernel address space will be needed when you don't
> know if a full configuration will fit into it.  The fact people use
> this patch at all is **EVIDENCE THAT THERE ALREADY IS A PROBLEM**
> with limiting kernel address space to 1GB.  And who the hell cares
> about a mouldy, antiquated ABI spec modeled after 1970 Unix technology
> anyway?  It should be another option for executable formats. All this
> ABI compatibility huey is some Intel/SCO pipe dream for supporting
> applications across multiple Unix platforms anyway. If it doesn't run
> on Linux, who the hell cares?
> :-)

Quoting placement  and linewrap are better, but it could still use
attributions. For instance, above your text that I quoted, I put:
"On Thu, Aug 26, 2004 at 09:08:19PM +0000, jmerkey@comcast.net wrote:"
which was actually generated automatically by my MUA, and similar above
text you quote would be helpful.

We already know there are problems surrounding virtualspace limitations
with respect to both efficiency and correctness. The "solutions" of
these kinds were not considered acceptable. To address these things in
general changes to common code to address virtualspace footprint issues
in a manner also benefitting 64-bit platforms are preferred to the full
exclusion of both static and dynamic kernel virtualspace inflation.
It's not a tremendously far-flung policy, though it limits the upper
range of memory sizes on legacy systems (32-bit with extended physical
addressing) that can be effectively supported by mainline somewhat.

In defense of my favorite company at the moment, Oracle does scale down
rather well to smaller system sizes within the limits of its own text's
memory footprint. I've successfully run OAST with as little as 256MB
RAM on my ia32-based laptop, at which point its ca. 50MB text footprint
is even a large proportion of memory. One should recall that the Oracle
database has a long history, and by virtue of such has run on very old
hardware configurations with very little RAM relative to modern systems,
so acquiring an acute awareness of its own memory footprint persisting
even to this day.

Also, SCO UNIX ABI emulation does exist in the form of iBCS, so there
is the further consideration of breaking that. Linux does in fact
emulate other OS's ABI's, so in the course of implementing ABI changes
one should also consider the ABI emulations affected by them.


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[linux]

>From MAILER-DAEMON Thu Aug 26 08:51:34 2004
Date: 26 Aug 2004 08:51:34 -0000
From: MAILER-DAEMON@horizon.com
To: linux@horizon.com
Subject: failure notice

This is an automated response from the e-mail delivery system at
horizon.com.  Your mail could not be delivered to one or more recipients.
This is a permanent error, so the message is being returned to you as
undeliverable.  The detailed error message is at the end of this text.
	
The most common reason that mail is not deliverable is that the specified
e-mail address does not exist.  horizon.com is Science Horizons, Inc.,
makers of seismic data acquisition equipment, with offices in Florida
and Missouri, USA.  We sometimes receive e-mail that is intended for a
different company entirely.  The most common are:
	- Horizon Airlines, horizonair.com
	- Horizon Organic Dairy, horizonorganic.com
	- Horizon Staffing Services, horizonstaff.com
	- Verizon Wireless, verizon.com
but there are many other companies with the word "horizon" in their name.
	
	
Please note that this response IS A RECORDING.	No human being has seen
your e-mail.  The header From: line of MAILER-DAEMON is the conventional
name for the source of such messages; it does not actually exist,
and mail to it is not accepted or read.  (The envelope sender, where
automated delivery messages are to be delivered, is the null address
"<>", as required by RFC 2821 section 6.1 for such bounce messages.)

If you wish to contact a human, the correct e-mail address is "postmaster"
(at whatever domain is of interest), as specified and required by RFC
2821 section 4.5.1.


The address to which your e-mail could not be delivered, and the specific
reason why, is:

<linux-kerne@vger.kernel.org>:
12.107.209.244 does not like recipient.
Remote host said: 554 Hi [192.35.100.1], 5.0.0 unresolvable address: <linux-kerne@vger.kernel.org>; nosuchuser; linux-kerne@vger.kernel.org
Giving up on 12.107.209.244.

--- Below this line is a copy of the message.

Return-Path: <linux@horizon.com>
Received: (qmail 22885 invoked by uid 1000); 26 Aug 2004 08:51:02 -0000
Date: 26 Aug 2004 08:51:02 -0000
Message-ID: <20040826085102.22884.qmail@science.horizon.com>
From: linux@horizon.com
To: linux-kerne@vger.kernel.org
Subject: Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)
Cc: 

William Lee Irwin III wrote:
> ELF ABI violation. "...the reserved area shall not consume more than
> 1GB of the address space."

and in another message:

> Though asinine, the ABI spec is set in stone.

So document that in Kconfig and violate away.

The point is that the vast majority of programs don't care.
Any program that uses a shared library can't depend on the exact size of
the address space that will be left to it.

I'm very dubious about a 1 GB user-land/3 GB kernel patch, but the
0xb0000000 patch (2.75/1.25) is damn useful to avoid HIGHMEM on 1 GB
RAM machines.  PAE requires the split to be on a 1 GB boundary, but
if you're using it to avoid highmem entirely, you're not running
PAE.  And normal page tables only require 4 MB granularity.

Ryan Cumming wrote:
> And at least one app (valgrind) chokes with as little as 1.25G of reserved 
> space.

You can mention that in the help, too.  But it's probably that valgrind
tries to put itself up there and present the debuged application with
the illusion of a smaller machine.  And to the extent that this works,
the debugged program doesn't care about the split, which actually proves
the point.

Valgrind can probably be hacked to cope fairly easily.

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Alan Cox]

On Iau, 2004-08-26 at 05:49, William Lee Irwin III wrote:
> On Wed, Aug 25, 2004 at 09:46:43PM -0700, Roland Dreier wrote:
> > Agreed, but I do like running with PAGE_OFFSET == 0xB0000000 on my
> > main box, which has 1 GB of RAM.  I can avoid highmem and still use
> > the last 128 MB of RAM.  It takes me about 3 seconds to edit
> > <asm/page.h> when I build a new kernel so I'm not arguing for merging
> > this, though.
> 
> Though asinine, the ABI spec is set in stone.

Lots of Linux configuration options build you systems that don't meet
some specifications. "Intentionally violate a stupid spec to get work
done" is a good option 8)

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Alan Cox]

On Sul, 2004-08-29 at 17:42, William Lee Irwin III wrote:
> On Iau, 2004-08-26 at 05:49, William Lee Irwin III wrote:
> The big nasty is that userspace has very little to go on here. We need
> to report the limits of the address space somewhere for this kind of
> affair and probably even hammer out our own addenda to ABI specs so
> instead of SVR4 $ARCH/ELF ABI spec we have a Linux $ARCH/ELF ABI spec.
> I see no one so motivated to make backward-incompatible ABI changes
> that they are willing to do that kind of work.

Ok so I can compile with a.out support. End of problem, that makes the
patch useful and "spec compliant", although the spec compliance is
irrelevant anyway. The spec doesn't determine what Linux is it's a
useful reference for normality. Special cases are special cases and you
harm the system by seeking to stop stuff that works purely for pieces of
paper.

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

On Iau, 2004-08-26 at 05:49, William Lee Irwin III wrote:
>> Though asinine, the ABI spec is set in stone.

On Sun, Aug 29, 2004 at 01:48:14PM +0100, Alan Cox wrote:
> Lots of Linux configuration options build you systems that don't meet
> some specifications. "Intentionally violate a stupid spec to get work
> done" is a good option 8)

The big nasty is that userspace has very little to go on here. We need
to report the limits of the address space somewhere for this kind of
affair and probably even hammer out our own addenda to ABI specs so
instead of SVR4 $ARCH/ELF ABI spec we have a Linux $ARCH/ELF ABI spec.
I see no one so motivated to make backward-incompatible ABI changes
that they are willing to do that kind of work.


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[William Lee Irwin III]

On Sul, 2004-08-29 at 17:42, William Lee Irwin III wrote:
>> The big nasty is that userspace has very little to go on here. We need
>> to report the limits of the address space somewhere for this kind of
>> affair and probably even hammer out our own addenda to ABI specs so
>> instead of SVR4 $ARCH/ELF ABI spec we have a Linux $ARCH/ELF ABI spec.
>> I see no one so motivated to make backward-incompatible ABI changes
>> that they are willing to do that kind of work.

On Sun, Aug 29, 2004 at 04:45:37PM +0100, Alan Cox wrote:
> Ok so I can compile with a.out support. End of problem, that makes the
> patch useful and "spec compliant", although the spec compliance is
> irrelevant anyway. The spec doesn't determine what Linux is it's a
> useful reference for normality. Special cases are special cases and you
> harm the system by seeking to stop stuff that works purely for pieces of
> paper.

Not quite. For one, it does actually break some apps. You can do it,
you just have to have some idea of what you're breaking and propagate
that onward somehow. Backward-incompatible userspace ABI changes can't
be undertaken as lightly as backward-incompatible kernel ABI changes.
There needs to be something that says "backward-incompatible ABI change
happened $HERE" somewhere people who aren't kernel hacking can find it.
There has to be some kind of warning somewhere; we can't just do it silently.


-- wli

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

> On Sul, 2004-08-29 at 17:42, William Lee Irwin III wrote:

> Ok so I can compile with a.out support. End of problem, that makes the
> patch useful and "spec compliant", although the spec compliance is
> irrelevant anyway. The spec doesn't determine what Linux is it's a
> useful reference for normality. Special cases are special cases and you
> harm the system by seeking to stop stuff that works purely for pieces of
> paper.
> 

Amen.  USB 2.0 orinoco wireless drivers seems to have problems when user space
is set to 1GB.  Works grat with 2GB ad 3GB user space settings.  Problem occurs during
any acces to usb_read_device().  This doesn't look like a ABI problem, looks like 
a problem with the USB subsystem.  The serialize semaphore gets stuck for some
reason. 

On the other topic, ABI compliance sounds a little restrictive since this is after all, an 
open source OS.  Most apps get recompiled and I always download open source 
components for Linux.  

:-)

Jeff

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Randy.Dunlap]

On Mon, 30 Aug 2004 04:01:29 +0000 jmerkey@comcast.net wrote:

| 
| 
| 
| > On Sul, 2004-08-29 at 17:42, William Lee Irwin III wrote:
| 
| > Ok so I can compile with a.out support. End of problem, that makes the
| > patch useful and "spec compliant", although the spec compliance is
| > irrelevant anyway. The spec doesn't determine what Linux is it's a
| > useful reference for normality. Special cases are special cases and you
| > harm the system by seeking to stop stuff that works purely for pieces of
| > paper.
| > 
| 
| Amen.  USB 2.0 orinoco wireless drivers seems to have problems when user space
| is set to 1GB.  Works grat with 2GB ad 3GB user space settings.  Problem occurs during
| any acces to usb_read_device().  This doesn't look like a ABI problem, looks like 
| a problem with the USB subsystem.  The serialize semaphore gets stuck for some
| reason. 

What kernel version?  I can't even find usb_read_device() in 2.6.9-rc1.

BTW, as someone else requested, please teach your mail client to wrap
lines around column 70-72.  Thanks.

| On the other topic, ABI compliance sounds a little restrictive since this is after all, an 
| open source OS.  Most apps get recompiled and I always download open source 
| components for Linux.  


--
~Randy

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

> What kernel version?  I can't even find usb_read_device() in 2.6.9-rc1.
> 
> BTW, as someone else requested, please teach your mail client to wrap
> lines around column 70-72.  Thanks.
> 
> ~Randy

linux-2.6.8.1.tar.gz

static ssize_t usb_device_read(struct file *file, 
                                                         char __user *buf, 
                                                         size_t nbytes, 
                                                         loff_t *ppos)
{
        struct list_head *buslist;
        struct usb_bus *bus;
        ssize_t ret, total_written = 0;
        loff_t skip_bytes = *ppos;
                                                                                
        if (*ppos < 0)
                return -EINVAL;
        if (nbytes <= 0)
                return 0;
        if (!access_ok(VERIFY_WRITE, buf, nbytes))
                return -EFAULT;
                                                                                
        /* enumerate busses */
        down (&usb_bus_list_lock);
        for (buslist = usb_bus_list.next; 
               buslist != &usb_bus_list; 
               buslist = buslist->next) {
                /* print devices for this bus */
                bus = list_entry(buslist, struct usb_bus, 
                                             bus_list);
                /* print devices for this bus */
                bus = list_entry(buslist, struct usb_bus, 
                                             bus_list);
                                                                                
                /* recurse through all children of the root hub */
                if (!bus->root_hub)
                        continue;

// IT BARFS RIGHT HERE -->
                down(&bus->root_hub->serialize);

Jeff

P.S.  I am using my comcast account which
is not as good as MUTT -- line wrap settings
since it is web based.  
drdos.com gets rejected
so I am typing less characters/line. :-)

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Randy.Dunlap]

On Mon, 30 Aug 2004 05:56:17 +0000 jmerkey@comcast.net wrote:

| 
| 
| 
| 
| > What kernel version?  I can't even find usb_read_device() in 2.6.9-rc1.
| > 
| > BTW, as someone else requested, please teach your mail client to wrap
| > lines around column 70-72.  Thanks.
| > 
| > ~Randy
| 
| linux-2.6.8.1.tar.gz


usb_device_read here (usb_read_device above :)


| static ssize_t usb_device_read(struct file *file, 
|                                                          char __user *buf, 
|                                                          size_t nbytes, 
|                                                          loff_t *ppos)
| {
|         struct list_head *buslist;
|         struct usb_bus *bus;
|         ssize_t ret, total_written = 0;
|         loff_t skip_bytes = *ppos;
|                                                                                 
|         if (*ppos < 0)
|                 return -EINVAL;
|         if (nbytes <= 0)
|                 return 0;
|         if (!access_ok(VERIFY_WRITE, buf, nbytes))
|                 return -EFAULT;
|                                                                                 
|         /* enumerate busses */
|         down (&usb_bus_list_lock);
|         for (buslist = usb_bus_list.next; 
|                buslist != &usb_bus_list; 
|                buslist = buslist->next) {
|                 /* print devices for this bus */
|                 bus = list_entry(buslist, struct usb_bus, 
|                                              bus_list);
|                 /* print devices for this bus */
|                 bus = list_entry(buslist, struct usb_bus, 
|                                              bus_list);
|                                                                                 
|                 /* recurse through all children of the root hub */
|                 if (!bus->root_hub)
|                         continue;
| 
| // IT BARFS RIGHT HERE -->
|                 down(&bus->root_hub->serialize);

It doesn't barf on me.  I added one other patch on top of yours:
one from Roland Dreier, for arch/i386/kernel/doublefault.c [below].

| P.S.  I am using my comcast account which
| is not as good as MUTT -- line wrap settings
| since it is web based.  
| drdos.com gets rejected
| so I am typing less characters/line. :-)
| -
Thanks.

--
~Randy



Looks like arch/i386/kernel/doublefault.c is one place in the code
that hardcodes the assumption that PAGE_OFFSET == 0xC0000000.  Here's
a patch that fixes that.

(Of course this doesn't really fix anything except debugging output)

 - Roland

Signed-off-by: Roland Dreier <roland@topspin.com>

Index: linux-2.6.8-rc1/arch/i386/kernel/doublefault.c
===================================================================
--- linux-2.6.8-rc1.orig/arch/i386/kernel/doublefault.c
+++ linux-2.6.8-rc1/arch/i386/kernel/doublefault.c
@@ -13,7 +13,7 @@
 static unsigned long doublefault_stack[DOUBLEFAULT_STACKSIZE];
 #define STACK_START (unsigned long)(doublefault_stack+DOUBLEFAULT_STACKSIZE)
 
-#define ptr_ok(x) ((x) > 0xc0000000 && (x) < 0xc1000000)
+#define ptr_ok(x) ((x) > PAGE_OFFSET && (x) < PAGE_OFFSET + 0x1000000)
 
 static void doublefault_fn(void)
 {
-

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Roland Dreier]

    Randy> It doesn't barf on me.  I added one other patch on top of
    Randy> yours: one from Roland Dreier, for
    Randy> arch/i386/kernel/doublefault.c [below].

BTW, I can't imagine my patch would make any difference -- it only
affects what gets printed out right before the kernel locks up on a
double fault.

I am running a 2.6.8.1 kernel with PAGE_OFFSET set to 0xb000000 on my
desktop with USB mouse and keyboard (and 1 GB of RAM) with no problems.

 - R.

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[jmerkey]

>     Randy> It doesn't barf on me.  I added one other patch on top of
>     Randy> yours: one from Roland Dreier, for
>     Randy> arch/i386/kernel/doublefault.c [below].
> 
> BTW, I can't imagine my patch would make any difference -- it only
> affects what gets printed out right before the kernel locks up on a
> double fault.
> 
> I am running a 2.6.8.1 kernel with PAGE_OFFSET set to 0xb000000 on my
> desktop with USB mouse and keyboard (and 1 GB of RAM) with no problems.
> 
>  - R.


I'll retest on 2.6.9-rc1  At present, the Orinoco 
Wireless USB Adapter does lock 
up my system when I enable 3BG kernel space.  
1 GB and 2 GB kernel address settings
seem to work OK.

Jeff

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Roland Dreier]

    Timothy> My question is: Why can't we just shrink the kernel
    Timothy> address space by that same amount, allowing the kernel
    Timothy> address space plus the extra to fit into 1GB?

If you have 1 GB of memory and want to map it all into the kernel's
address space and the kernel has only 1 GB of address space total,
then there is no room for anything else (such as address space to
ioremap memory-mapped peripherals or space for vmalloc allocations).
Therefore, if you want to have 1 GB of RAM mapped linearly into the
kernel's address space, you need strictly more than 1 GB of kernel
address space.  In practice, 1.25 GB of kernel address space (a
PAGE_OFFSET value of 0xb0000000) works well with 1 GB of RAM.  That's
what I run on my main desktop machine with 1 GB of RAM to avoid HIGHMEM.

 - Roland

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Timothy Miller]

I feel like I've missed something in this discussion.

First of all I really don't understand the cause of the lost 128K in the 
first place, but it seems that by increasing the address space reserved 
for the kernel in user space by some amount fixes this problem.

My question is:  Why can't we just shrink the kernel address space by 
that same amount, allowing the kernel address space plus the extra to 
fit into 1GB?

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Timothy Miller]

Roland Dreier wrote:
>     Timothy> My question is: Why can't we just shrink the kernel
>     Timothy> address space by that same amount, allowing the kernel
>     Timothy> address space plus the extra to fit into 1GB?
> 
> If you have 1 GB of memory and want to map it all into the kernel's
> address space and the kernel has only 1 GB of address space total,
> then there is no room for anything else (such as address space to
> ioremap memory-mapped peripherals or space for vmalloc allocations).
> Therefore, if you want to have 1 GB of RAM mapped linearly into the
> kernel's address space, you need strictly more than 1 GB of kernel
> address space.  In practice, 1.25 GB of kernel address space (a
> PAGE_OFFSET value of 0xb0000000) works well with 1 GB of RAM.  That's
> what I run on my main desktop machine with 1 GB of RAM to avoid HIGHMEM.
> 
>  - Roland
> 
> 


Ok, I understand now.  I think.  With 0xc0000000, you have 128M of 
highmem, right?  Why do you add 256M to the kernel address space?  Is 
there a further advantage to that?

Re: 1GB/2GB/3GB User Space Splitting Patch 2.6.8.1 (PSEUDO SPAM)

[Roland Dreier]

    Timothy> Ok, I understand now.  I think.  With 0xc0000000, you
    Timothy> have 128M of highmem, right?  Why do you add 256M to the
    Timothy> kernel address space?  Is there a further advantage to that?

No real reason, just laziness.  It's easier to change "0xc" to "0xb"
and not think rather than figuring out if 0xb8000000 will let me use
every last byte of RAM.  (I'm not sure if I end up with exactly 128 MB
of highmem, or perhaps a shade more)  For userspace, there's no
practical difference between having 2.75 GB of address space and 2.875
GB given that I have only 1 GB of real RAM.

 - Roland