On Fri, 21 Jan 2005 18:20:51 -0800,
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>Luck, Tony wrote on Friday, January 21, 2005 5:03 PM
>> >- __gp = ADDR(.got) + 0x20;
>> >+ __gp = _end - 0x20;
>>
>> Did we used to link the ".got" section earlier? It's after "data" now,
>> but the expres
Christoph Lameter writes:
> I had the name "zero_page" in V1 and V2 of the patch where it was
> separate. Then someone complained about code duplication.
Well, if you duplicated each arch's clear_page implementation in
zero_page, then yes, that would be unnecessary code duplication. I
would sugg
Luck, Tony wrote on Friday, January 21, 2005 5:03 PM
> >- __gp = ADDR(.got) + 0x20;
> >+ __gp = _end - 0x20;
>
> Did we used to link the ".got" section earlier? It's after "data" now,
> but the expression used there might have made sense if ".got" was before
> the "data".
>
> _end - 0x20
On Sat, 22 Jan 2005, Paul Mackerras wrote:
> Christoph's patch is bigger than it needs to be because he has to
> change all the occurrences of clear_page(x) to clear_page(x, 0), and
> then he has to change a lot of architectures' clear_page functions to
> be called _clear_page instead. If he pick
Andrew Morton writes:
> It is, actually, from the POV of the page allocator. It's a "higher order
> page" and is controlled by a struct page*, just like a zero-order page...
So why is the function that gets me one of these "higher order pages"
called "get_free_pages" with an "s"? :)
Christoph's
Hi,
On Fri, 21 Jan 2005, Andrew Morton wrote:
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
> >
> > A cluster of 2^n contiguous pages
> > isn't one page by any normal definition.
>
> It is, actually, from the POV of the page allocator. It's a "higher order
> page" and is controlled by a struct p
Andrew Morton writes:
> It is, actually, from the POV of the page allocator. It's a "higher order
> page" and is controlled by a struct page*, just like a zero-order page...
OK. I still reckon it's confusing terminology for the rest of us who
don't have our heads deep in the page allocator code
>- __gp = ADDR(.got) + 0x20;
>+ __gp = _end - 0x20;
Did we used to link the ".got" section earlier? It's after "data" now,
but the expression used there might have made sense if ".got" was before
the "data".
_end - 0x20 may work for you now, but won't this be very configuration
de
On Fri, 21 Jan 2005 15:22:18 -0800,
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>__gp is positioned so far out that it is almost at the end of all data
>sections. On 2.6.11-rc1, 80% of kernel data symbols are out of 22-bit
>immediate offset from __gp. This means accessing these symbols are
>un
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> A cluster of 2^n contiguous pages
> isn't one page by any normal definition.
It is, actually, from the POV of the page allocator. It's a "higher order
page" and is controlled by a struct page*, just like a zero-order page...
-
To unsubscribe from thi
__gp is positioned so far out that it is almost at the end of all data
sections. On 2.6.11-rc1, 80% of kernel data symbols are out of 22-bit
immediate offset from __gp. This means accessing these symbols are
unnecessarily expansive such that they have to go through global offset
table (a memory
Christoph Lameter writes:
> clear_page clears one page of the specified order.
Now you're really being confusing. A cluster of 2^n contiguous pages
isn't one page by any normal definition. Call it "clear_page_cluster"
or "clear_page_order" or something, but not "clear_page".
Paul.
-
To unsubsc
On Sat, 22 Jan 2005, Paul Mackerras wrote:
> Christoph Lameter writes:
>
> > The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c
> > may benefit from a
> > clear_page that is capable of zeroing multiple pages at once (and scrubd
> > too but that is now an independent patch
Christoph Lameter writes:
> The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c
> may benefit from a
> clear_page that is capable of zeroing multiple pages at once (and scrubd
> too but that is now an independent patch). The following patch extends
> clear_page with a seco
Hi Tony:
I don't believe this has been submitted. It removes many compiler warnings.
thanks,
bob
Signed-off-by: Bob Picco <[EMAIL PROTECTED]>
diff -ruNp -X /home/picco/losl/dontdiff
linux-2.6.11-rc1-mm1-mhp1-orig/arch/ia64/lib/bitop.c
linux-2.6.11-rc1-mm1-mhp1/arch/ia64/lib/bitop.c
--- linu
The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c may
benefit from a
clear_page that is capable of zeroing multiple pages at once (and scrubd
too but that is now an independent patch). The following patch extends
clear_page with a second parameter specifying the order of
This patch adds a new function alloc_zeroed_user_highpage that is then used in
the
anonymous page fault handler and in the COW code to allocate zeroed pages. The
function
can be defined per arch to setup special processing for user pages by defining
__HAVE_ARCH_ALLOC_ZEROED_USER_PAGE. For arches
David Mosberger wrote on Thursday, January 20, 2005 9:53 AM:
> Please disregard the patch named in $SUBJECT. It appears to be
> breaking light-weight syscalls. That's rather odd, but since Rohit
> has some better ideas on how to fix this issue, I'd rather drop this
> patch for the time being (th
The current way of updating ptes in the Linux vm includes first clearing
a pte before setting it to another value. The clearing is performed while
holding the page_table_lock to insure that the entry will not be modified
by the CPU directly, by an arch specific interrupt handler or another page
fau
When I converted the sn2 code over to the new DMA API, I left the old routines
in place and added wrappers to call them from the generic DMA API functions.
This added an unnecessary level of obfuscation since the generic ia64 code
calls those functions when any of the old style PCI DMA API func
- irq_desc and irq_to_vector machvecs. SN2 has it's own versions,
but they're the same as the generic ones
- kill do do_IRQ and use __do_IRQ directly everywhere
- kill dead X86 ifdefs
- move some variable declarations around in irq.c to recuce # of ifdefs
--- 1.54/arch/ia64/kernel/irq.c
SCOTLAND INTERNATIONAL LOTTERY PROMOTIONS.
NOVEMBER/DECEMBER YEAR ENDING DRAW.
FS.9081- EDINBURGH- SCOTLAND.
Attn.
Entry No.STL/19051663/SLT.
RE:Your Scotland Lottery Winning Claim Notice.
We are pleased to inform you, today the 21th of January, 2005. The result
of the long awaited draw of th
On 20 Jan 2005, at 6:07 am, David Mosberger wrote:
We just discovered a nasty bug in glibc-2.3.2 which can lead to
"random" memory corruption in multi-threaded applications using NPTL.
This definitely affects Debian/{testing,unstable}, but it may affect
other distros as well. I also believe that t
> "Jesse" == Jesse Barnes <[EMAIL PROTECTED]> writes:
Jesse> On Thursday, January 20, 2005 1:03 am, Jes Sorensen wrote:
>> What about real memory and mapping it uncached? Do we need to play
>> the same trick before allowing it to be mapped uncached? and for IO
>> memory mapped uncached?
Jesse
> "David" == David Mosberger <[EMAIL PROTECTED]> writes:
> On 20 Jan 2005 04:03:19 -0500, Jes Sorensen <[EMAIL PROTECTED]> said:
Jes> Trying to map real memory uncached was what made me stumble upon
Jes> the PREFETCH_VISIBILITY limitation in the PAL code.
David> I assume you're using this
25 matches
Mail list logo
