On Thu, 3 Feb 2005, Andrew Morton wrote:
> Which implies that we need to see some additional accounting code, so we
> can verify that the base accumulation infrastructure is doing the expected
> thing. As well as an ack from the interested parties. Does anyone know
> what's happening with all the
Bjorn Helgaas schrieb:
The most recent 2.4 patch for ia64 is here:
ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.4/linux-2.4.26-ia64-040510.diff.bz2
I haven't been producing 2.4 patches recently because I don't
think anyone would actually use them.
My assumption is that most people using
On Wed, 2005-02-02 at 14:09 +1100, Nick Piggin wrote:
> On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote:
> > On Wed, 2 Feb 2005, Nick Piggin wrote:
> > I mean we could just speculatively copy, risk copying crap and
> > discard that later when we find that the pte has changed. This would
On Thu, 3 Feb 2005 20:09:57 -0600,
Jack Steiner <[EMAIL PROTECTED]> wrote:
>On Thu, Feb 03, 2005 at 05:48:26PM -0600, Russ Anderson wrote:
>> According to the SAL Spec, MCAs are supposed to be handled
>> one at a time.
>
>It has been a long time since I looked, but I thought the
>spec allowed ei
> On Thu, 3 Feb 2005 12:33:40 +0530, Vaibhav Sharma <[EMAIL PROTECTED]>
> said:
Vaibhav> Hi, Thanks a lot for a quick response, I appreciate. If
Vaibhav> you could only help me out a little more $,1s&(B.
Vaibhav> See, I need to change some of the boot parameters as
Vaibhav> re
On Thu, Feb 03, 2005 at 05:48:26PM -0600, Russ Anderson wrote:
> Tony Luck wrote:
> >
> > Also I noticed that ia64_sal_to_os_handoff_state
> > hasn't been replicated ... won't we need that too?
>
> According to the SAL Spec, MCAs are supposed to be handled
> one at a time.
It has been a long t
> On Thu, 3 Feb 2005 15:38:54 -0800, "H. J. Lu" <[EMAIL PROTECTED]> said:
HJ> I got
HJ> arch/ia64/lib/memset.S:62: Warning: .save outside of prologue
Good catch!
--david
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PRO
> On 03 Feb 2005 15:58:16 -0500, Jes Sorensen <[EMAIL PROTECTED]> said:
Jes> I hear your concerns! However, at the same time, if something
Jes> within the kernel starts mocking with memory it doesn't own,
Jes> thats a bug.
I'm not convinced of that. Jack already mentioned lcrash...
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Well your patch certainly cleans things up in there and would be a good
> thing to have as long as we can be sure that it doesn't break the
> accounting in some subtle way.
I think it also fits well with the other accounting data which is only
statistic
Tony Luck wrote:
>
> Also I noticed that ia64_sal_to_os_handoff_state
> hasn't been replicated ... won't we need that too?
According to the SAL Spec, MCAs are supposed to be handled
one at a time.
I would like that to change, so that multiple independent
MCAs could be handled in parallel, but
I got
arch/ia64/lib/memset.S:62: Warning: .save outside of prologue
H.J.
--- linux/arch/ia64/lib/memset.S.unwind 2005-02-03 10:46:27.0 -0800
+++ linux/arch/ia64/lib/memset.S2005-02-03 15:35:36.0 -0800
@@ -57,10 +57,10 @@ GLOBAL_ENTRY(memset)
{ .mmi
.prologue
On Thu, 2005-02-03 at 12:18 -0800, H. J. Lu wrote:
> I am testing the ia64 assembler changes on 2.4 and 2.6 kernel. Which
> 2.4 kernel tree should I use?
The most recent 2.4 patch for ia64 is here:
ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.4/linux-2.4.26-ia64-040510.diff.bz2
I hav
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> I hope that Roland's changes for higher resolution of cputime would
> make that possible. But this is Jay's thing not mine. I just want to make
> sure that the CSA patches does not get in the way of our attempts to
> improve the performance of the pa
This patch helps some (all uses of ia64_mca_data in
mca_asm.S need to deref the pointer to get at the
actual space, instead of clobbering thigs in the
percpu area).
Also I noticed that ia64_sal_to_os_handoff_state
hasn't been replicated ... won't we need that too?
-Tony
forruss.patch
Descriptio
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Has any performance testing been done?
Jay did some performance testing and found minor performance increases
without my page fault patches. But then the performance without the page
fault patches is already so bad due to the page_table_lock
contention t
The new assembler doesn't like
.proc memcpy
.endp memcpy
.proc __copy_user
.endp memcpy
.endp __copy_user
H.J.
--- linux-2.4.21/arch/ia64/lib/memcpy_mck.S.endp2005-02-03
12:20:36.0 -0800
+++ linux-2.4.21/arch/ia64/lib/memcpy_mck.S
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> As requested by Andrew:
>
> In the 2.6.11 development cycle function calls have been added to lots
> of hot vm paths to do accounting. I think these should not go into the
> final 2.6.1 release because these statistics can be collected in a differen
>Aha, I wasn't aware of this, I thought the region registers worked
>like some giant TLB. I'll add a flush for the granule when it's pulled
>into the allocator.
No, the Alt-DTLB miss handler in ivt.S will blindly insert TLB
entries to fix any faults in region 6 or 7 ... giving the illusion
that
As requested by Andrew:
In the 2.6.11 development cycle function calls have been added to lots
of hot vm paths to do accounting. I think these should not go into the
final 2.6.1 release because these statistics can be collected in a different
way that does not require the updating of counters from
> "Jack" == Jack Steiner <[EMAIL PROTECTED]> writes:
Jack> On Thu, Feb 03, 2005 at 03:38:45AM -0500, Jes Sorensen wrote:
Jack> sorry - I mised your reply. Apparantly, it looks like SPAM:
Urgh, Barracuda! No comment ;-(
Jack> On Wed, Feb 02, 2005 at 02:10:32PM -0500, Jes Sorensen wrote:
Jack
After a quick glance over the patch:
- There are several lines introduced with trailing whitespace (some
of them long). If you use emacs, you can get rid of them
with delete-trailing-whitespace. Please do so.
- I'm not a fan of coding retry-loops with labels; I'd much rather
have the
I am testing the ia64 assembler changes on 2.4 and 2.6 kernel. Which
2.4 kernel tree should I use?
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Thu, 3 Feb 2005 12:54:06 -0600, Jack Steiner <[EMAIL PROTECTED]> said:
Jack> Am I being overly paranoid?
I don't think so. Your concerns are hitting the nail on the head...
--david
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a messag
On Wed, Jan 19, 2005 at 06:51:20PM +, Matthew Wilcox wrote:
>
> This patch converts acpiphp to use the generic PCI resource assignment
> code. It's quite large, but most of it is deleting the acpiphp_pci and
> acpiphp_res files. It's tested on an hp Integrity rx8620 (which won't
> work witho
On Thu, Feb 03, 2005 at 12:08:05PM -0700, Bjorn Helgaas wrote:
> Convert pci_raw_ops to use unsigned segment (aka domain),
> bus, and devfn. With the previous code, various ia64 config
> accesses fail due to segment sign-extension problems.
>
> ia64:
> - With a signed seg >= 0x8, unwanted sig
Convert pci_raw_ops to use unsigned segment (aka domain),
bus, and devfn. With the previous code, various ia64 config
accesses fail due to segment sign-extension problems.
ia64:
- With a signed seg >= 0x8, unwanted sign-extension occurs when
"seg << 28" is cast to u64 in PCI_SAL_EXT_ADD
On Thu, Feb 03, 2005 at 03:38:45AM -0500, Jes Sorensen wrote:
> > "Jack" == Jack Steiner <[EMAIL PROTECTED]> writes:
sorry - I mised your reply. Apparantly, it looks like SPAM:
>>> Subject: * SUSPECTED SPAM * Re: [rfc] generic allocator and mspec
>>> driver
>>> From: Jes Sorensen <[
On Wednesday, February 2, 2005 11:47 pm, Jes Sorensen wrote:
> > "Jesse" == Jesse Barnes <[EMAIL PROTECTED]> writes:
>
> Jesse> On Wednesday, February 2, 2005 11:10 am, Jes Sorensen wrote:
> >> The remaining issue I am facing is that for the uncached pool I
> >> want to make it node aware and w
On Thu, Feb 03, 2005 at 09:55:26AM -0500, Jes Sorensen wrote:
> Is this because the applications will normally allocate their fetchops
> in the main thread before spawning off the threads? If the mmap is
> done by the thread that will 'own' the individual fetchop this
> wouldn't be a problem? Sorry
>
> > "Robin" == Robin Holt <[EMAIL PROTECTED]> writes:
>
> Jack> Ugly hack. Isn't there a better way? (I know this isn't your
> Jack> code & you probably don't like this either. I had hoped for a
> Jack> cleaner solution in 2.6)
> >> It's gross, ugly and I hate it ... not sure if there'
On Thursday, February 3, 2005 12:38 am, Jes Sorensen wrote:
> Jack> ... + printk(KERN_WARNING "smp_call_function failed for " +
> Jack> "mspec_ipi_visibility! (%i)\n", status); + } + +
> Jack> sn_flush_all_caches((unsigned long)tmp, IA64_GRANULE_SIZE);
>
> Jack> Don't the TLBs need to be flushed b
I noticed that almost every architecture has some variant of:
#define INIT_THREAD_INFO(tsk) \
[...]
.preempt_count = 1,\
except for parisc, ia64 and arm26. parisc and arm26 don't have functional
PREEMPT, so I suspect can simply be changed. How abo
> "Robin" == Robin Holt <[EMAIL PROTECTED]> writes:
Jack> Ugly hack. Isn't there a better way? (I know this isn't your
Jack> code & you probably don't like this either. I had hoped for a
Jack> cleaner solution in 2.6)
>> It's gross, ugly and I hate it ... not sure if there's a simpler
>>
> Jack> Ugly hack. Isn't there a better way? (I know this isn't your
> Jack> code & you probably don't like this either. I had hoped for a
> Jack> cleaner solution in 2.6)
>
> It's gross, ugly and I hate it ... not sure if there's a simpler way.
> Maybe we can use the same approach as the fbme
Hi,
(B
(BI have posted the patch for vector sharing (large I/O system
(Bsupport) several months ago, and I would like to try again.
(BThe following is updated patch against 2.6.11-rc3.
(B
(BTony, could you consider applying this patch onto your test
(Btree? I hope this patch will be tested b
> "Jack" == Jack Steiner <[EMAIL PROTECTED]> writes:
Jack> On Wed, Feb 02, 2005 at 02:10:32PM -0500, Jes Sorensen wrote:
Jack> General comment:
Jack, thanks for the comments, I'll look at it, however I have the
following comments (which may or may not be correct from my side):
Jack> 1) I may
That is correct. However, to comply with this *AND* emit an error when a
symbol mentioned with .proc wasn't defined before the .endp, more
substantial changes to the assembler would be necessary (it would have
to keep track of all the symbols mentioned in .proc, which it currently
doesn't). I can c
37 matches
Mail list logo
