From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Edward Spidre <beamz_owl@yahoo.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Possible PCI subsystem bug in 2.4
Date: Fri, 4 May 2001 13:34:11 +0200 (MEST) [thread overview]
Message-ID: <200105041134.NAA03383@cave.bitwizard.nl> (raw)
In-Reply-To: <Pine.LNX.4.21.0105031106030.30573-100000@penguin.transmeta.com> from Linus Torvalds at "May 3, 2001 11:12:04 am"
Linus Torvalds wrote:
>
> On Thu, 3 May 2001, Alan Cox wrote:
> >
> > Obvious one is to go to the next power of two clear.
>
> The question is mainly _which_ power of two.
>
> I don't think we can round up infinitely, as that might just end up
> causing us to not have any PCI space at all. Or we could end up deciding
> that real PCI space is memory, and then getting a clash when a real device
> tries to register its bios-allocated area that clashes with our extreme
> rounding.
>
> I suspect it would be safe to round up to the next megabyte, possibly up
> to 64MB or so. But much more would make me nervous.
>
> Any suggestions?
The amount of RAM in a machine almost always has just one or two "1"
bits.
8, 16, 20, 24, 32, 36, 40, 48, 64, 80 Mb were the numbers that you'd
see in the early Pentium times, right?
So rounding up would mean: Add one until the number of 1-bits in the
address is less than 3. People with 3 or more differently sized DIMMS
in their machine will experience a slightly ineffcient round-up.
Speed this up with: Find-lowest-1-bit, add that.
Example you quoted:
nr of 1 bits.
BIOS-proclaimed end-of-ram: 0x13fff0000 15
lowest 1-bit: 0x000010000 1
add: 0x140000000 2
long round_highmem (long val)
{
while (hweight32 (val) > 2)
val += 1 << ffs (val);
return val;
}
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
next prev parent reply other threads:[~2001-05-04 11:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010503140318.7583.qmail@web10704.mail.yahoo.com>
2001-05-03 17:08 ` Possible PCI subsystem bug in 2.4 Linus Torvalds
2001-05-03 17:51 ` Alan Cox
2001-05-03 18:12 ` Linus Torvalds
2001-05-03 18:22 ` Jeff Garzik
2001-05-03 18:31 ` Alan Cox
2001-05-04 15:41 ` Eric W. Biederman
2001-05-04 15:52 ` Alan Cox
2001-05-04 16:13 ` Eric W. Biederman
2001-05-04 17:04 ` Alan Cox
2001-05-05 5:41 ` Eric W. Biederman
2001-05-08 16:01 ` Maciej W. Rozycki
2001-05-09 15:45 ` Eric W. Biederman
2001-05-04 17:44 ` Linus Torvalds
2001-05-05 5:30 ` Eric W. Biederman
2001-05-05 7:17 ` Alan Cox
2001-05-04 11:34 ` Rogier Wolff [this message]
[not found] <20010503191655.67673.qmail@web10701.mail.yahoo.com>
2001-05-03 19:28 ` Linus Torvalds
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=200105041134.NAA03383@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=beamz_owl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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