On 9/7/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> On Friday 07 September 2007 02:38:07 am Jes Sorensen wrote:
> > The reason why I suggested a machvec is to avoid cluttering up the
> > generic function with something like this. In addition I only see two
> > machvec's that may potentially get c
On Friday 07 September 2007 02:38:07 am Jes Sorensen wrote:
> The reason why I suggested a machvec is to avoid cluttering up the
> generic function with something like this. In addition I only see two
> machvec's that may potentially get copied, the dig one and the hpzx1
> one.
>
> If we start add
Luck, Tony wrote:
So far it appears to me that it will be defined for ia64 somewhere in
asm-generic/tlb.h and in asm-ia64/tlb.h as
platform_global_tlb_ipi_purge() something, but I'm not sure about
that, will have to start digging.
I'm voting with David on this one ... machvec doesn't look like
> So far it appears to me that it will be defined for ia64 somewhere in
> asm-generic/tlb.h and in asm-ia64/tlb.h as
> platform_global_tlb_ipi_purge() something, but I'm not sure about
> that, will have to start digging.
I'm voting with David on this one ... machvec doesn't look like
the right mec
On 9/6/07, David Mosberger-Tang <[EMAIL PROTECTED]> wrote:
> Natalie,
>
> I'm confused. In an earlier mail, you wrote:
>
> > The boot option is only temporary, until the SAL/PAL mechanism will be
> > shaken up.
>
> Once the SAL/PAL mechanism exists, there won't be a need for
> bootoption or a se
Natalie,
I'm confused. In an earlier mail, you wrote:
> The boot option is only temporary, until the SAL/PAL mechanism will be
> shaken up.
Once the SAL/PAL mechanism exists, there won't be a need for
bootoption or a separate machvec anymore, or am I missing something?
The other thing that m
On 9/5/07, David Mosberger-Tang <[EMAIL PROTECTED]> wrote:
> In my opinion, machvec is a bad idea for a temporary workaround.
> You'll need to create new header files etc etc all just for a
> short-lived workaround. Just my 2 cents.
>
> --david
This is actually a feature. Can be a workaround fo
In my opinion, machvec is a bad idea for a temporary workaround.
You'll need to create new header files etc etc all just for a
short-lived workaround. Just my 2 cents.
--david
On 9/5/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Robin Holt <[EMAIL PROTECTED]> wrote:
> > > No
On 9/5/07, Robin Holt <[EMAIL PROTECTED]> wrote:
> > No :) those interested are big hardware makers of large scaled out
> > boxes, such as HP, UIS. They are using own asics and are not
> > necessarily being able to keep chipset native capabilities intact. As
> > I said in the preamble, the mechanis
> No :) those interested are big hardware makers of large scaled out
> boxes, such as HP, UIS. They are using own asics and are not
> necessarily being able to keep chipset native capabilities intact. As
> I said in the preamble, the mechanism has to be there so they can turn
> the ptc.g off and ru
Natalie Protasevich wrote:
On 03 Sep 2007 05:21:41 -0400, Jes Sorensen <[EMAIL PROTECTED]> wrote:
The boot option is only temporary, until the SAL/PAL mechanism will be
shaken up.
I will digest and use the machvec then, how about that? For now I'd
like to provide this revived patch as is for it
On 9/4/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote:
> > This patch allows to disable ptc.g. The code used to be in the kernel, then
> > was removed
> > in 2.4 since the bug that it was fixing has gone away. However, some large
>
On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote:
> This patch allows to disable ptc.g. The code used to be in the kernel, then
> was removed
> in 2.4 since the bug that it was fixing has gone away. However, some large
> system vendors
> now want this capability available throu
On 03 Sep 2007 05:21:41 -0400, Jes Sorensen <[EMAIL PROTECTED]> wrote:
> > "Natalie" == Natalie Protasevich <[EMAIL PROTECTED]> writes:
>
> Natalie> From: Natalie Protasevich <[EMAIL PROTECTED]>
>
> Natalie> This patch allows to disable ptc.g. The code used to be in
> Natalie> the kernel, then
On 9/4/07, Luck, Tony <[EMAIL PROTECTED]> wrote:
> >> global cache purge in their chipset implementation. (For such cases, Intel
> >> provided a SAL
> >> table entry to specify if ptc.g is allowed and how many).
> >
> > This seems odd. You never use that sal call to initialized noptcg.
> > Is tha
>> global cache purge in their chipset implementation. (For such cases, Intel
>> provided a SAL
>> table entry to specify if ptc.g is allowed and how many).
>
> This seems odd. You never use that sal call to initialized noptcg.
> Is that an oversight?
The mechanism is a SAL table entry, not a S
Please don't take this as a review. I only glanced over it while waiting
for coffee to brew.
How does this align with sn2's tlb shootdown mechanism? It seems similar
in intent.
On Mon, Sep 03, 2007 at 01:06:20AM -0700, Natalie Protasevich wrote:
> global cache purge in their chipset implementa
> From: Natalie Protasevich <[EMAIL PROTECTED]>
> This patch allows to disable ptc.g. The code used to be in the
> kernel, then was removed in 2.4 since the bug that it was fixing has
> gone away. However, some large system vendors now want this
> capability available through a means that can be
> "Natalie" == Natalie Protasevich <[EMAIL PROTECTED]> writes:
Natalie> From: Natalie Protasevich <[EMAIL PROTECTED]>
Natalie> This patch allows to disable ptc.g. The code used to be in
Natalie> the kernel, then was removed in 2.4 since the bug that it was
Natalie> fixing has gone away. Howev
From: Natalie Protasevich <[EMAIL PROTECTED]>
This patch allows to disable ptc.g. The code used to be in the kernel, then was
removed
in 2.4 since the bug that it was fixing has gone away. However, some large
system vendors
now want this capability available through a means that can be contro
On Fri, 2007-08-31 at 04:38, Natalie Protasevich wrote:
> From: Natalie Protasevich <[EMAIL PROTECTED]>
>
> This patch allows to disable ptc.g. The code used to be in the kernel, then
> was removed in 2.4 since the bug that it was fixing has gone away. However,
> some large system vendors now wa
From: Natalie Protasevich <[EMAIL PROTECTED]>
This patch allows to disable ptc.g. The code used to be in the kernel, then
was removed in 2.4 since the bug that it was fixing has gone away. However,
some large system vendors now want this capability available through a means
that can be control
22 matches
Mail list logo
