On Thu, 19 Jul 2007 17:18:59 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
>
> > Hmm...but the current code flushes the page. just do it in "lazy" way.
> > much difference ?
>
> I agree the current code flushes the I-cache for all kinds of file
> systems (for PTEs
KAMEZAWA Hiroyuki wrote:
Hmm...but the current code flushes the page. just do it in "lazy" way.
much difference ?
I agree the current code flushes the I-cache for all kinds of file
systems (for PTEs with the exec bit on).
The error is that it does it after the PTE is written.
In addition, I
On Thu, 19 Jul 2007 16:15:03 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> We may have, say 1 Gbyte / sec local i/o activity (using some RAIDs).
> Assume a few % of this 1 Gbyte is the program execution, or program swap in.
> It gives some hundreds of new exec pages / sec =>
> some msec-s
KAMEZAWA Hiroyuki wrote:
A bit new idea. How about this ?
==
- Set PG_arch_1 if "icache is *not* coherent"
page-flags.h:
* PG_arch_1 is an architecture specific page state bit. The generic code
* guarantees that this bit is cleared for a page when it first is entered into
* the page cache.
KAMEZAWA Hiroyuki wrote:
But is it too costly that flushing icache page only if a page is newly
installed into the system (PG_arch1) && it is mapped as executable ?
Well it was a bit long time ago, I measured on a Tiger box with
CPUs of 1.3 GHz:
Flushing a page of 64 Kbytes, with modified
On Thu, 19 Jul 2007 22:01:18 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jul 2007 14:05:06 +0200
> Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
>
> > KAMEZAWA Hiroyuki wrote:
> >
> > > Then, what should I do more for fixing this SIGILL problem ?
> > >
> > > -Kame
> >
> > I
On Thu, 19 Jul 2007 14:05:06 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
>
> > Then, what should I do more for fixing this SIGILL problem ?
> >
> > -Kame
>
> I can think of a relatively cheap solution:
>
Maybe I should take performance numbers with the patch.
Back to do_no_page():
if the new PTE includes the exec bit and PG_arch_1 is set,
the page has to be flushed from the I-cache before the PTE is
made globally visible.
Sorry, I wanted to say:
if the new PTE includes the exec bit and PG_arch_1 is NOT set
Thanks,
Zoltan
-
To unsubscribe from
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively cheap solution:
New pages are allocated with the bit PG_arch_1 off, see
page_cache_read() ... prep_new_page(), i.e. the I-cache is
not coherent with the D-cache.
On Fri, 6 Jul 2007 11:29:01 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> This is a patch for fixing icache flush race in ia64(Montecito) by
> implementing
> flush_icache_page() at el.
>
> Changelog:
> - updated against 2.6.22-rc7 (previous one was against 2.6.21)
> - removed
On Fri, 6 Jul 2007 11:29:01 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
This is a patch for fixing icache flush race in ia64(Montecito) by
implementing
flush_icache_page() at el.
Changelog:
- updated against 2.6.22-rc7 (previous one was against 2.6.21)
- removed hugetlbe's
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively cheap solution:
New pages are allocated with the bit PG_arch_1 off, see
page_cache_read() ... prep_new_page(), i.e. the I-cache is
not coherent with the D-cache.
Back to do_no_page():
if the new PTE includes the exec bit and PG_arch_1 is set,
the page has to be flushed from the I-cache before the PTE is
made globally visible.
Sorry, I wanted to say:
if the new PTE includes the exec bit and PG_arch_1 is NOT set
Thanks,
Zoltan
-
To unsubscribe from
On Thu, 19 Jul 2007 14:05:06 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively cheap solution:
Maybe I should take performance numbers with the patch.
But is it too
On Thu, 19 Jul 2007 22:01:18 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007 14:05:06 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively
KAMEZAWA Hiroyuki wrote:
But is it too costly that flushing icache page only if a page is newly
installed into the system (PG_arch1) it is mapped as executable ?
Well it was a bit long time ago, I measured on a Tiger box with
CPUs of 1.3 GHz:
Flushing a page of 64 Kbytes, with modified data
KAMEZAWA Hiroyuki wrote:
A bit new idea. How about this ?
==
- Set PG_arch_1 if icache is *not* coherent
page-flags.h:
* PG_arch_1 is an architecture specific page state bit. The generic code
* guarantees that this bit is cleared for a page when it first is entered into
* the page cache.
On Thu, 19 Jul 2007 16:15:03 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
We may have, say 1 Gbyte / sec local i/o activity (using some RAIDs).
Assume a few % of this 1 Gbyte is the program execution, or program swap in.
It gives some hundreds of new exec pages / sec =
some msec-s can be
KAMEZAWA Hiroyuki wrote:
Hmm...but the current code flushes the page. just do it in lazy way.
much difference ?
I agree the current code flushes the I-cache for all kinds of file
systems (for PTEs with the exec bit on).
The error is that it does it after the PTE is written.
In addition, I
On Thu, 19 Jul 2007 17:18:59 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Hmm...but the current code flushes the page. just do it in lazy way.
much difference ?
I agree the current code flushes the I-cache for all kinds of file
systems (for PTEs with the exec
On Fri, 06 Jul 2007 11:41:38 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
>
> > Note1: icache flush is called only when VM_EXEC flag is on and
> > PG_arch_1 is not set.
>
> If you have not got the page in the cache, then the new page will
> be allocated
KAMEZAWA Hiroyuki wrote:
Note1: icache flush is called only when VM_EXEC flag is on and
PG_arch_1 is not set.
If you have not got the page in the cache, then the new page will
be allocated with PG_arch_1 bit off.
You are going to flush pages which are read by HW DMA, i.e. the L2I
of
KAMEZAWA Hiroyuki wrote:
Note1: icache flush is called only when VM_EXEC flag is on and
PG_arch_1 is not set.
If you have not got the page in the cache, then the new page will
be allocated with PG_arch_1 bit off.
You are going to flush pages which are read by HW DMA, i.e. the L2I
of
On Fri, 06 Jul 2007 11:41:38 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Note1: icache flush is called only when VM_EXEC flag is on and
PG_arch_1 is not set.
If you have not got the page in the cache, then the new page will
be allocated with
This is a patch for fixing icache flush race in ia64(Montecito) by implementing
flush_icache_page() at el.
Changelog:
- updated against 2.6.22-rc7 (previous one was against 2.6.21)
- removed hugetlbe's lazy_mmu_prot_update().
- rewrote patch description.
- removed patch against mprotect() if
This is a patch for fixing icache flush race in ia64(Montecito) by implementing
flush_icache_page() at el.
Changelog:
- updated against 2.6.22-rc7 (previous one was against 2.6.21)
- removed hugetlbe's lazy_mmu_prot_update().
- rewrote patch description.
- removed patch against mprotect() if
26 matches
Mail list logo
