Martin Bligh wrote:
> Christoph Lameter wrote:
>> On Fri, 16 Mar 2007, Martin Bligh wrote:
>>
>>> You have to do some sort of lookup anyway, and Andy seemed to have them
>>> all folded into one.
>>
>> What lookup would you need to do? On x86_64 even the TLB use is hidden
>> by the existing 2M entri
> And those machines are basically identical to perfectly regular i386
> platforms.
For modern (2001+) i386 platforms sure. The problem is the old and the weird.
>
> So the whole argument that it would "diverge" is total crap. It obviously
> won't diverge, simply because the support for old se
On Fri, 16 Mar 2007, Andi Kleen wrote:
> > In the future it is likely that x86_64 will significantly deviate from
>
> It already is in some cases. And I agree more will happen.
This is a *totally* bogus and idiotic argument.
x86-64 will get new capabilities, BUT IT WILL CONTINUE TO SUPPORT O
On Fri, 16 Mar 2007, Christoph Lameter wrote:
>
> Yes he has already explained it and I am well aware of the difficulties
> on 32 bit. -> linux-mm archives.
Stop pointing to archives.
If you cannot give a http pointer to a specific thread, don't bother with
the "please real the list" thing A
On Fri, 16 Mar 2007, Martin Bligh wrote:
> For starters, you can't do that sparse a mapping on a 32 bit system.
> I'll let Andy explain the rest of it.
Yes he has already explained it and I am well aware of the difficulties
on 32 bit. -> linux-mm archives.
> "the agreement"? So Andy agreed to t
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you try
On Fri, 2007-03-16 at 13:15 -0700, Christoph Lameter wrote:
> On Fri, 16 Mar 2007, Andi Kleen wrote:
> > > x86_64 is going to acquire more functionality that will not be available
> > > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
> >
> > What advantage would that hav
On Fri, 16 Mar 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
>
> > Please read my posts to linux-mm on that subject. We discussed it last
> > year in detail and the agreement was that the sparsemem crud needs to be
> > take
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:56:13 -0700 (PDT)
> On Fri, 16 Mar 2007, David Miller wrote:
>
> > From: Christoph Lameter <[EMAIL PROTECTED]>
> > Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
> >
> > > Please read my posts to linux-mm on that subject. We disc
On Fri, 16 Mar 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
>
> > Virtual mmap allows holes in the same way as page tables do.
>
> I don't want to take expensive TLB misses to lookup a page.
Ummm. You are missing key detai
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
> Virtual mmap allows holes in the same way as page tables do.
I don't want to take expensive TLB misses to lookup a page.
Don't force a virtual mapping solution down my throat if that
is not what I believe a
On Fri, 16 Mar 2007, David Miller wrote:
> > It is primarily a performance improvement since the sparsemem table
> > lookups would no longer be necessary and it also streamlines other
> > frequent cacheline uses. These page -> page_struct and vice versa
> > operations are key to the performance
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
> Please read my posts to linux-mm on that subject. We discussed it last
> year in detail and the agreement was that the sparsemem crud needs to be
> taken out. Kame-san posted patches to do that.
Please don
On Fri, 16 Mar 2007, Martin Bligh wrote:
> You have to do some sort of lookup anyway, and Andy seemed to have them
> all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
> Or are you trying to avoid this by goin
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:15:38 -0700 (PDT)
> On Fri, 16 Mar 2007, Andi Kleen wrote:
>
> > > x86_64 is going to acquire more functionality that will not be available
> > > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
> >
>
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle hol
On Fri, 16 Mar 2007, Andi Kleen wrote:
>
> > x86_64 is going to acquire more functionality that will not be available
> > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
>
> What advantage would that have over the current setup?
> We already should handle holes between
> In the future it is likely that x86_64 will significantly deviate from
It already is in some cases. And I agree more will happen.
> i386. i386 is going to be gradually abandoned because it does not support
> the ever larger memory sizes and be mainly used for embedded devices.
The desktop/s
On Thu, 15 Mar 2007, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another. There are lots
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote:
> [Hopefully fixed email client to make it to the list this time]
> [This series has changed by using git-diff -M]
> Seems appropriate, but I really don't care what it's called. One thing about
> this name, is that typing arch/x86 doesn't t
On Mar 15 2007 08:59, Linus Torvalds wrote:
>On Thu, 15 Mar 2007, Martin Bligh wrote:
>>
>> Can't we move the shared files into a new shared arch/ subdirectory
>> (ia32_64 or whatever), and have them included from both places?
>
>That's *exactly* what the patches do (except it's called "arch/x86"
> You could do both. Have the x86 directory that Linus suggests for shared
> files, then have the build system generate the symlinks for you.
Symlinks are usually a bad idea because they tend to not work with objdirs.
We did that in 2.4.
-Andi
-
To unsubscribe from this list: send the line "unsu
On Thu, 2007-03-15 at 18:01 +0100, Andi Kleen wrote:
> > Oops, sorry, you did say "in the includes". Yeah, that holds the same
> > crap that I'm talking about.
>
> It's a simple and obvious solution that does exactly what it is
> supposed to do. Why do you call it crap?
Yes, it's a simple sol
> Oops, sorry, you did say "in the includes". Yeah, that holds the same
> crap that I'm talking about.
It's a simple and obvious solution that does exactly what it is
supposed to do. Why do you call it crap?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Thu, 2007-03-15 at 12:47 -0400, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another. Th
Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
symbolic links perhaps? In that case i'd also introduce a common
naming scheme: x86_early_printk.c - to make sure we know it right
away that those files are bi-arch.
Hey, I know! This is a radical idea, but what if we put the na
On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
> Well I just see a lot of pain from these patches but I doubt
> they will avoid any bugs. If people don't compile test both
> archs they will always likely break on another. There are lots
> of subtle dependencies that are not expressed in the
On Thu, 15 Mar 2007, Andi Kleen wrote:
> > That's *exactly* what the patches do (except it's called "arch/x86", which
> > is clearly the best option - please don't use "ia" _anywhere_ except for
> > "ia64", since that's the only architecture that is really "intel
> > architecture").
>
> And
> That's *exactly* what the patches do (except it's called "arch/x86", which
> is clearly the best option - please don't use "ia" _anywhere_ except for
> "ia64", since that's the only architecture that is really "intel
> architecture").
And i860 @)
> > On the downside, it's more ../../.. type
On Thu, 15 Mar 2007, Martin Bligh wrote:
>
> Can't we move the shared files into a new shared arch/ subdirectory
> (ia32_64 or whatever), and have them included from both places?
That's *exactly* what the patches do (except it's called "arch/x86", which
is clearly the best option - please don'
Linus Torvalds wrote:
On Wed, 14 Mar 2007, Ingo Molnar wrote:
and that's how i think unification of architectures should be done: move
code into kernel/* and drivers/*, _not_ into another architecture. That
way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
On Mar 14 2007 21:21, Andi Kleen wrote:
>
>> also, having the x32_ and x64_ prefix is a painful daily reminder for
>> all of us changing the architecture that 'this stuff needs to be
>> unified!'.
>
>We would probably stuck with that forever and it just looks ugly.
>Non paravirt xen uses such a
> the basic dynamics of legacies does not change if we have only 50% of
> them: right now x86_64 is just growing its own set of legacies, at the
> same rate as i386 did it 10 years ago.
Modern system are much more similar to each other than older systems
due to Windows forcing them and they are
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Andrew's laptop only half a dozen times! ;) But .. in the long run,
> > it's alot easier to think about unified code. 32-bit x86 will
> > certainly stay with us for at least 10-20 years, and the best model
> > for maintainance is having one codebase.
> also, having the x32_ and x64_ prefix is a painful daily reminder for
> all of us changing the architecture that 'this stuff needs to be
> unified!'.
We would probably stuck with that forever and it just looks ugly.
Non paravirt xen uses such a setup and I always hated it.
Besides the archite
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Well, I'd like it to be 100% _eventually_, and just unify the
> > architectures.
>
> ok, having a single bi-arch final tree is indeed intriquing and i didnt
> realize that you were suggesting that. [...]
>
> [...] But this really scares the sh*t out
> the x86_64 and i386 trees have diverged quite a bit though, so this will
> be a major logistical undertaking. And with Andi opposed to
> fundamentally it it also lacks a bit of manpower i guess :-/
I'm not fundamentally opposed, just sceptical on the effort:gain ratio.
> Andrew's laptop only
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code,
> > a total of 128825. That means we move about 10% of the code. Not
> > insignificant but not earth-shattering either. With alot more effort
> > (and testing) we could realisti
Andi Kleen wrote:
> Only do it where it makes sense and is not too intrusive.
> Redoing the whole port just for lguest64 is probably not a good idea.
Well, at some point Xen is going to be 64-bit. We need a 64-bit
paravirt_ops, and it looks to me that 90% of the entrypoints will be
more or less i
On Wed, Mar 14, 2007 at 09:36:35AM -0400, Steven Rostedt wrote:
> On Wed, 2007-03-14 at 14:05 +0100, Andi Kleen wrote:
> > > The thing is others and I (and you) are working on getting paravirt_ops
> > > working for x86_64. There's a lot of overlap between i386 and x86_64.
> > > Right now the i386
On Wed, Mar 14, 2007 at 11:36:08AM +0100, Andi Kleen wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common ground
> > for all code that is shared between x86_64 and i386. I called this
> >
> >arch/x86
>
> NACK. I think
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> then i decided to analyze the patches: currently they move 13452 lines
> of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code, a
> total of 128825. That means we move about 10% of the code. Not
> insignificant but not earth-shattering
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > symbolic links perhaps? In that case i'd also introduce a common
> > naming scheme: x86_early_printk.c - to make sure we know it right
> > away that those files are bi-arch.
>
> Hey, I know! This is a radical idea, but what if we put the name at
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Did you even *look* at the patches?
yes. I am strongly in favor of sharing code - i recently introduced
arch/x86_64/kernel/tsc_sync.c that is shared by i386 too.
So first i wrote a draft email where i told Andi that he's on crack to
NACK it so bru
On Wed, 14 Mar 2007, Steven Rostedt wrote:
>
> That's created at build time. But I don't see anywhere in a freshly
> cloned repo or fresh untar of the linux tarball, where there exists any
> symbolic links.
There are none.
Symlinks embedded in the source tree tend to be hard to maintain: you
On Wed, 2007-03-14 at 17:33 +0100, Jan Engelhardt wrote:
> On Mar 14 2007 10:46, Steven Rostedt wrote:
> >
> >> symbolic links perhaps? In that case i'd also introduce a common naming
> >> scheme: x86_early_printk.c - to make sure we know it right away that
> >> those files are bi-arch.
> >
> >Do
On Wed, 14 Mar 2007, Jan Engelhardt wrote:
> >
> >Seems appropriate, but I really don't care what it's called. One thing about
> >this name, is that typing arch/x86 doesn't tab complete x86_64 anymore.
> >But if you can think of something better, I'd be happy to apply it.
>
> 80x86
> 8086
> ia3
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> symbolic links perhaps? In that case i'd also introduce a common naming
> scheme: x86_early_printk.c - to make sure we know it right away that
> those files are bi-arch.
Hey, I know! This is a radical idea, but what if we put the name at the
head o
On Mar 14 2007 10:46, Steven Rostedt wrote:
>
>> symbolic links perhaps? In that case i'd also introduce a common naming
>> scheme: x86_early_printk.c - to make sure we know it right away that
>> those files are bi-arch.
>
>Does the Linux code tree already support sym links? IOW, are there
>alre
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> and that's how i think unification of architectures should be done: move
> code into kernel/* and drivers/*, _not_ into another architecture. That
> way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
We're talking ab
On Wed, 14 Mar 2007, Andi Kleen wrote:
>
> NACK. I think the current ways work just fine.
Andi, the current ways do *not* work just fine.
I don't understand why you have problems with obvious cleanups. You also
nack'ed the file movement to at least make this kind of thing consistent
(ie th
On Wed, 2007-03-14 at 14:41 +0100, Ingo Molnar wrote:
> hm. Do you have any numbers handy - what is the end-result of your
> unification work, how many lines of code were unified, compared to the
> total body of code in i386 and x86_64?
Well, I wasn't combining code that wasn't already combined
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > i agree. We've recently factored out quite a bit of common code
> > between i386 and x86_64 recently: genirq, gtod/clocksource and
> > clockevents.
>
> But those are things that can mostly be shared across all archs.
yeah.
> > and that's how i
On Wed, 2007-03-14 at 14:05 +0100, Andi Kleen wrote:
> > The thing is others and I (and you) are working on getting paravirt_ops
> > working for x86_64. There's a lot of overlap between i386 and x86_64.
> > Right now the i386 is ahead of x86_64 and the code seems to be put more
> > in the arch/i38
On Wed, 2007-03-14 at 13:53 +0100, Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> > >
> > > So I spent last night hacking up something to try to make a common
> > > ground for all code that is shared between x86_64 and i386. I
>
> The thing is others and I (and you) are working on getting paravirt_ops
> working for x86_64. There's a lot of overlap between i386 and x86_64.
> Right now the i386 is ahead of x86_64 and the code seems to be put more
> in the arch/i386 arch. So now we are going to introduce a
> new ../../i386
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common
> > ground for all code that is shared between x86_64 and i386. I
> > called this
> >
> >arch/x86
>
> NACK. I think the current
On Wed, 2007-03-14 at 11:36 +0100, Andi Kleen wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common ground
> > for all code that is shared between x86_64 and i386. I called this
> >
> >arch/x86
>
> NACK. I think the cu
Hi,
I am newbie developing a routing application which
needs three features;
1. if the fib lookup fails, my application needs to know about using
preferably
netlink, -- any direction to some sample code or files in the kernel???
2. I need a counter recording the hits a fib entry is chosen for
p
Steven Rostedt <[EMAIL PROTECTED]> writes:
>
> So I spent last night hacking up something to try to make a common ground
> for all code that is shared between x86_64 and i386. I called this
>
>arch/x86
NACK. I think the current ways work just fine.
-Andi
-
To unsubscribe from this list:
On Mar 14 2007 01:08, Steven Rostedt wrote:
>
>So I spent last night hacking up something to try to make a common ground
>for all code that is shared between x86_64 and i386. I called this
>
> arch/x86
>
>Seems appropriate, but I really don't care what it's called. One thing about
>this name,
[Hopefully fixed email client to make it to the list this time]
[This series has changed by using git-diff -M]
Recently I've been doing some work that will affect both the i386 and x86_64
architectures. So there will be common code for both, as well as code
that will be unique for the specific ar
62 matches
Mail list logo
