Hello Stephen,
Stephen C. Tweedie wrote:
> First, don't we want to do a flush_page_to_ram() *before* starting the
> swap IO?
Well, let me explain the issue. It is the thing we need to do
flushing *after* I/O.
--
Problem with virtually indexed physically tagged
Hi,
On Thu, Jun 28, 2001 at 09:07:52AM +0900, NIIBE Yutaka wrote:
> Marcelo Tosatti wrote:
> > I think Stephen C. Tweedie has some considerations about the cache
> > flushing calls on do_swap_page().
>
> Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
> tried at first)
On Thu, 28 Jun 2001, NIIBE Yutaka wrote:
> Marcelo Tosatti wrote:
> > I think Stephen C. Tweedie has some considerations about the cache
> > flushing calls on do_swap_page().
>
> Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
> tried at first) is not good, because
Marcelo Tosatti wrote:
> I think Stephen C. Tweedie has some considerations about the cache
> flushing calls on do_swap_page().
Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
tried at first) is not good, because it's the hot path and it causes
another performance problem
Hi,
I think Stephen C. Tweedie has some considerations about the cache
flushing calls on do_swap_page().
Stephen?
On Wed, 27 Jun 2001, NIIBE Yutaka wrote:
> Hello Marcelo,
>
> This is follow-up to the mail in February. You may perhaps forget the
> context, it's the bug of MM about
Hi,
I think Stephen C. Tweedie has some considerations about the cache
flushing calls on do_swap_page().
Stephen?
On Wed, 27 Jun 2001, NIIBE Yutaka wrote:
Hello Marcelo,
This is follow-up to the mail in February. You may perhaps forget the
context, it's the bug of MM about cache
Marcelo Tosatti wrote:
I think Stephen C. Tweedie has some considerations about the cache
flushing calls on do_swap_page().
Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
tried at first) is not good, because it's the hot path and it causes
another performance problem
On Thu, 28 Jun 2001, NIIBE Yutaka wrote:
Marcelo Tosatti wrote:
I think Stephen C. Tweedie has some considerations about the cache
flushing calls on do_swap_page().
Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
tried at first) is not good, because it's the
Hi,
On Thu, Jun 28, 2001 at 09:07:52AM +0900, NIIBE Yutaka wrote:
Marcelo Tosatti wrote:
I think Stephen C. Tweedie has some considerations about the cache
flushing calls on do_swap_page().
Yup. IIRC, he said that flushing cache at do_swap_page() (which I've
tried at first) is not
Hello Marcelo,
This is follow-up to the mail in February. You may perhaps forget the
context, it's the bug of MM about cache flushing for swapped-in-pages.
I see this bug on SuperH port (SH-4).
I think that we have this issue on the machine whose flush_dcache_page()
is defined. In current
Hello Marcelo,
This is follow-up to the mail in February. You may perhaps forget the
context, it's the bug of MM about cache flushing for swapped-in-pages.
I see this bug on SuperH port (SH-4).
I think that we have this issue on the machine whose flush_dcache_page()
is defined. In current
On Wed, 14 Feb 2001, NIIBE Yutaka wrote:
> Alan Cox wrote:
> > Ok we need to handle that case a bit more intelligently so those flushes dont
> > get into other ports code paths.
>
> Possibly at fs/buffer.c:end_buffer_io_async?
>
> We need to flush the cache when I/O was READ or READA.
Yet
On Wed, 14 Feb 2001, NIIBE Yutaka wrote:
Alan Cox wrote:
Ok we need to handle that case a bit more intelligently so those flushes dont
get into other ports code paths.
Possibly at fs/buffer.c:end_buffer_io_async?
We need to flush the cache when I/O was READ or READA.
Yet another
Alan Cox wrote:
> Ok we need to handle that case a bit more intelligently so those flushes dont
> get into other ports code paths.
Possibly at fs/buffer.c:end_buffer_io_async?
We need to flush the cache when I/O was READ or READA. Is there any
way for end_buffer_io_async to distinguish
Russell King wrote:
> Unless someone else (Rik/DaveM) says otherwise, it is my understanding
> that any IO for page P will only ever be a write to disk. Therefore,
> when you get a copy of the page from the swap cache, the physical memory
> for that page is the same as it was when the
> Suppose there's I/O to the physical page P asynchronously, and the
> page is placed in the swap cache. It remains cache entry, say,
> indexed kernel virtual address K. Then, process maps P at U. U and K
> (may) indexes differently. The process will get the data from memory
> (not the one in
NIIBE Yutaka writes:
> My case (SH-4) is: virtual address indexed, physical address tagged cache
> (which has alias issue).
vivt caches have the same alias issue.
> Suppose there's I/O to the physical page P asynchronously, and the
> page is placed in the swap cache.
Unless someone else
Russell King wrote:
> What was the problem? The old code seems to behave well on a virtual
> address indexed virtual address tagged cache.
My case (SH-4) is: virtual address indexed, physical address tagged cache
(which has alias issue).
Suppose there's I/O to the physical page P
Marcelo Tosatti writes:
> If lookup_swap_cache() finds a page in the swap cache, and that page was
> in memory because of the swapin readahead, the cache is not flushed.
>
> Here is a patch to fix the problem by always flushing the cache including
> for pages in the swap cache:
> -
> -
Marcelo Tosatti writes:
If lookup_swap_cache() finds a page in the swap cache, and that page was
in memory because of the swapin readahead, the cache is not flushed.
Here is a patch to fix the problem by always flushing the cache including
for pages in the swap cache:
-
-
Russell King wrote:
What was the problem? The old code seems to behave well on a virtual
address indexed virtual address tagged cache.
My case (SH-4) is: virtual address indexed, physical address tagged cache
(which has alias issue).
Suppose there's I/O to the physical page P
NIIBE Yutaka writes:
My case (SH-4) is: virtual address indexed, physical address tagged cache
(which has alias issue).
vivt caches have the same alias issue.
Suppose there's I/O to the physical page P asynchronously, and the
page is placed in the swap cache.
Unless someone else
Suppose there's I/O to the physical page P asynchronously, and the
page is placed in the swap cache. It remains cache entry, say,
indexed kernel virtual address K. Then, process maps P at U. U and K
(may) indexes differently. The process will get the data from memory
(not the one in the
Russell King wrote:
Unless someone else (Rik/DaveM) says otherwise, it is my understanding
that any IO for page P will only ever be a write to disk. Therefore,
when you get a copy of the page from the swap cache, the physical memory
for that page is the same as it was when the process
Alan Cox wrote:
Ok we need to handle that case a bit more intelligently so those flushes dont
get into other ports code paths.
Possibly at fs/buffer.c:end_buffer_io_async?
We need to flush the cache when I/O was READ or READA. Is there any
way for end_buffer_io_async to distinguish which
Hi,
Niibe Yutaka noted (and added an entry on the MM bugzilla system) that
cache flushing on do_swap_page() is buggy. Here:
---
struct page *page = lookup_swap_cache(entry);
pte_t pte;
if (!page) {
lock_kernel();
26 matches
Mail list logo
