All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs
Date: Fri, 09 May 2003 20:02:47 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590723705709@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705550@msgid-missing>

> 
> >>>>> On Fri, 9 May 2003 10:52:25 -0700, Jesse Barnes <jbarnes@sgi.com> said:
> 
>   Jesse> So, is there any consensus on the best path to pursue?  Chris Wedgwood
>   Jesse> is working on option #3, and I've got Tony's patch trimmed down to #2
>   Jesse> (with one piece missing--ia64_switch_to runtime patching), but none of
>   Jesse> these are in either 2.4 or 2.5 yet.  Maybe for 2.4 we should do #2 or
>   Jesse> #3 and for 2.5 we could implement #1 with the virtual offsets Tony
>   Jesse> mentioned earlier?
> 
> I'm not sure.  I got the impression Tony may be looking at the virtual
> remapping in region 5.  I haven't heard whether text replication
> turned out to be important for 8870, but I'm starting to lean towards
> virtual remapping because it is more versatile (can handle both
> "strange" physical memory layouts and kernel replication).  This,
> coupled with the fact that it doesn't break any of the existing tools
> makes it pretty compelling.  Also, my primary objection about making
> the kernel model more complicated doesn't hold much water if we move
> everything to region 5.
> 
> Would there be a downside to this on SGI's machines?

I dont see any significant problems. It actually seems easy.

I think we still need to use __tpa() for addresses assigned by the loader.
The standard __pa() macros wont work in region 5. 

I dont have any objections to __tpa.  We have had them in the kernel 
since ~2.3.42 & have not had any problems with them. On occasion, when 
we upgrade, we have to add/delete a couple of references but these are 
always easy to find. I dont recall any changes for the last couple of upgrades
but maybe we were just lucky.

As I mention in mail earlier, 

>> The __tpa macros are ugly but they are fully contained within the ia64 part
>> of the tree. (IIRC, the old scheduler had a reference but the O(1) scheduler doe not).
>> In our tree, there are currently only 12 references to __tpa. All are
>> in boottime initialization code, mostly in mca.c.  Although I would
>> rather not have __tpa, this doesnt seem too bad.



> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 


-- 
Thanks

Jack Steiner    (651-683-5302)   (vnet 233-5302)      steiner@sgi.com



  parent reply	other threads:[~2003-05-09 20:02 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17 23:05 [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs David Mosberger
2003-04-17 23:57 ` Jesse Barnes
2003-04-25 21:02 ` Jesse Barnes
2003-05-07 22:39 ` David Mosberger
2003-05-07 23:24 ` Luck, Tony
2003-05-07 23:51 ` David Mosberger
2003-05-08  0:00 ` Jesse Barnes
2003-05-08  0:04 ` Jesse Barnes
2003-05-08  0:07 ` Luck, Tony
2003-05-08  0:13 ` Keith Owens
2003-05-08  0:21 ` David Mosberger
2003-05-08  0:23 ` David Mosberger
2003-05-08  0:24 ` Keith Owens
2003-05-08  0:54 ` David Mosberger
2003-05-08  1:07 ` David Mosberger
2003-05-08  1:46 ` Jesse Barnes
2003-05-08  1:55 ` Keith Owens
2003-05-08  2:16 ` Keith Owens
2003-05-08  4:59 ` David Mosberger
2003-05-08 16:07 ` Jesse Barnes
2003-05-08 17:07 ` David Mosberger
2003-05-08 17:20 ` Jesse Barnes
2003-05-08 17:50 ` David Mosberger
2003-05-08 17:54 ` Luck, Tony
2003-05-08 20:29 ` David Mosberger
2003-05-08 22:17 ` Keith Owens
2003-05-08 22:27 ` Luck, Tony
2003-05-08 22:31 ` Jesse Barnes
2003-05-08 22:53 ` David Mosberger
2003-05-08 23:32 ` David Mosberger
2003-05-09  0:01 ` Jesse Barnes
2003-05-09  0:11 ` Jesse Barnes
2003-05-09 17:52 ` Jesse Barnes
2003-05-09 18:25 ` David Mosberger
2003-05-09 19:30 ` Jesse Barnes
2003-05-09 19:31 ` Jack Steiner
2003-05-09 20:02 ` Jack Steiner [this message]
2003-05-09 20:25 ` David Mosberger
2003-05-09 21:43 ` Luck, Tony
2003-05-10  2:39 ` Jack Steiner
2003-05-13 22:18 ` Luck, Tony
2003-05-14  1:24 ` Jesse Barnes
2003-05-14  5:29 ` Christian Hildner
2003-05-14 16:44 ` Luck, Tony
2003-05-15  3:05 ` David Mosberger
2003-05-15 16:33 ` Luck, Tony
2003-05-15 18:03 ` Jack Steiner
2003-05-15 18:59 ` David Mosberger
2003-05-15 21:43 ` Luck, Tony
2003-05-16 22:33 ` Luck, Tony
2003-05-16 22:47 ` David Mosberger
2003-05-16 22:54 ` [Linux-ia64] " Luck, Tony
2003-05-16 22:58 ` David Mosberger
2003-05-19 17:57 ` Luck, Tony
2003-05-19 18:02 ` Jesse Barnes
2003-05-19 18:39 ` David Mosberger
2003-05-19 19:07 ` Luck, Tony
2003-05-28 19:10 ` Luck, Tony
2003-05-28 20:05 ` Luck, Tony
2003-05-28 20:13 ` Luck, Tony

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=marc-linux-ia64-105590723705709@msgid-missing \
    --to=steiner@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.