* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 5:51 ` MinChan Kim
0 siblings, 0 replies; 22+ messages in thread
From: MinChan Kim @ 2009-01-16 5:51 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linux-mm, linux-fsdevel, npiggin, akpm
On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 16, 2009 at 02:28:04PM +0900, MinChan Kim wrote:
> > Now, Anyone don't maintain cramfs.
> > I don't know who is maintain romfs. so I send this patch to linux-mm,
> > lkml, linux-dev.
> >
> > I am not sure my thought is right.
> >
> > When readpage is called, page with argument in readpage is just new
> > allocated because kernel can't find that page in page cache.
> >
> > At this time, any user process can't map the page to their address space.
> > so, I think D-cache aliasing probelm never occur.
> >
> > It make sense ?
>
> Sorry, no. You have to call fluch_dcache_page() in two situations --
> when the kernel is going to read some data that userspace wrote, *and*
> when userspace is going to read some data that the kernel wrote. From a
> quick look at the patch, this seems to be the second case. The kernel
> wrote data to a pagecache page, and userspace should be able to read it.
>
> To understand why this is necessary, consider a processor which is
> virtually indexed and has a writeback cache. The kernel writes to a
> page, then a user process reads from the same page through a different
> address. The cache doesn't find the data the kernel wrote because it
> has a different virtual index, so userspace reads stale data.
I see. :)
Thanks for quick reponse and good explaination.
Hmm,.. one more question.
I can't find flush_dcache_page call in mpage_readpage which is
generic read function. In case of ext fs, it use mpage_readpage
with readpage.
who and where call flush_dcache_page in mpage_readpage call path?
>
> --
> Matthew Wilcox Intel Open Source Technology Centre
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours. We can't possibly take such
> a retrograde step."
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 5:51 ` MinChan Kim
@ 2009-01-16 5:57 ` Matthew Wilcox
-1 siblings, 0 replies; 22+ messages in thread
From: Matthew Wilcox @ 2009-01-16 5:57 UTC (permalink / raw)
To: MinChan Kim; +Cc: linux-kernel, linux-mm, linux-fsdevel, npiggin, akpm
On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > when the kernel is going to read some data that userspace wrote, *and*
> > when userspace is going to read some data that the kernel wrote. From a
> > quick look at the patch, this seems to be the second case. The kernel
> > wrote data to a pagecache page, and userspace should be able to read it.
> >
> > To understand why this is necessary, consider a processor which is
> > virtually indexed and has a writeback cache. The kernel writes to a
> > page, then a user process reads from the same page through a different
> > address. The cache doesn't find the data the kernel wrote because it
> > has a different virtual index, so userspace reads stale data.
>
> I see. :)
>
> Thanks for quick reponse and good explaination.
> Hmm,.. one more question.
>
> I can't find flush_dcache_page call in mpage_readpage which is
> generic read function. In case of ext fs, it use mpage_readpage
> with readpage.
>
> who and where call flush_dcache_page in mpage_readpage call path?
Most I/O devices will do DMA to the page in question and thus the kernel
hasn't written to it and the CPU won't have the data in cache. For the
few devices which can't do DMA, it's the responsibility of the device
driver to call flush_dcache_page() (or some other flushing primitive).
See the gdth driver for an example:
address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
memcpy(address, buffer, cpnow);
flush_dcache_page(sg_page(sl));
kunmap_atomic(address, KM_BIO_SRC_IRQ);
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 5:57 ` Matthew Wilcox
0 siblings, 0 replies; 22+ messages in thread
From: Matthew Wilcox @ 2009-01-16 5:57 UTC (permalink / raw)
To: MinChan Kim; +Cc: linux-kernel, linux-mm, linux-fsdevel, npiggin, akpm
On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > when the kernel is going to read some data that userspace wrote, *and*
> > when userspace is going to read some data that the kernel wrote. From a
> > quick look at the patch, this seems to be the second case. The kernel
> > wrote data to a pagecache page, and userspace should be able to read it.
> >
> > To understand why this is necessary, consider a processor which is
> > virtually indexed and has a writeback cache. The kernel writes to a
> > page, then a user process reads from the same page through a different
> > address. The cache doesn't find the data the kernel wrote because it
> > has a different virtual index, so userspace reads stale data.
>
> I see. :)
>
> Thanks for quick reponse and good explaination.
> Hmm,.. one more question.
>
> I can't find flush_dcache_page call in mpage_readpage which is
> generic read function. In case of ext fs, it use mpage_readpage
> with readpage.
>
> who and where call flush_dcache_page in mpage_readpage call path?
Most I/O devices will do DMA to the page in question and thus the kernel
hasn't written to it and the CPU won't have the data in cache. For the
few devices which can't do DMA, it's the responsibility of the device
driver to call flush_dcache_page() (or some other flushing primitive).
See the gdth driver for an example:
address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
memcpy(address, buffer, cpnow);
flush_dcache_page(sg_page(sl));
kunmap_atomic(address, KM_BIO_SRC_IRQ);
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 5:57 ` Matthew Wilcox
@ 2009-01-16 6:08 ` MinChan Kim
-1 siblings, 0 replies; 22+ messages in thread
From: MinChan Kim @ 2009-01-16 6:08 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linux-mm, linux-fsdevel, npiggin, akpm
On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> > On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > > when the kernel is going to read some data that userspace wrote, *and*
> > > when userspace is going to read some data that the kernel wrote. From a
> > > quick look at the patch, this seems to be the second case. The kernel
> > > wrote data to a pagecache page, and userspace should be able to read it.
> > >
> > > To understand why this is necessary, consider a processor which is
> > > virtually indexed and has a writeback cache. The kernel writes to a
> > > page, then a user process reads from the same page through a different
> > > address. The cache doesn't find the data the kernel wrote because it
> > > has a different virtual index, so userspace reads stale data.
> >
> > I see. :)
> >
> > Thanks for quick reponse and good explaination.
> > Hmm,.. one more question.
> >
> > I can't find flush_dcache_page call in mpage_readpage which is
> > generic read function. In case of ext fs, it use mpage_readpage
> > with readpage.
> >
> > who and where call flush_dcache_page in mpage_readpage call path?
>
> Most I/O devices will do DMA to the page in question and thus the kernel
> hasn't written to it and the CPU won't have the data in cache. For the
> few devices which can't do DMA, it's the responsibility of the device
> driver to call flush_dcache_page() (or some other flushing primitive).
Hmm.. Now I am confusing.
If devicer driver or with DMA makes sure cache consistency,
Why filesystem code have to handle it ?
> See the gdth driver for an example:
>
> address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
> memcpy(address, buffer, cpnow);
> flush_dcache_page(sg_page(sl));
> kunmap_atomic(address, KM_BIO_SRC_IRQ);
>
> --
> Matthew Wilcox Intel Open Source Technology Centre
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours. We can't possibly take such
> a retrograde step."
--
Kinds regards,
MinChan Kim
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 6:08 ` MinChan Kim
0 siblings, 0 replies; 22+ messages in thread
From: MinChan Kim @ 2009-01-16 6:08 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linux-mm, linux-fsdevel, npiggin, akpm
On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> > On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > > when the kernel is going to read some data that userspace wrote, *and*
> > > when userspace is going to read some data that the kernel wrote. From a
> > > quick look at the patch, this seems to be the second case. The kernel
> > > wrote data to a pagecache page, and userspace should be able to read it.
> > >
> > > To understand why this is necessary, consider a processor which is
> > > virtually indexed and has a writeback cache. The kernel writes to a
> > > page, then a user process reads from the same page through a different
> > > address. The cache doesn't find the data the kernel wrote because it
> > > has a different virtual index, so userspace reads stale data.
> >
> > I see. :)
> >
> > Thanks for quick reponse and good explaination.
> > Hmm,.. one more question.
> >
> > I can't find flush_dcache_page call in mpage_readpage which is
> > generic read function. In case of ext fs, it use mpage_readpage
> > with readpage.
> >
> > who and where call flush_dcache_page in mpage_readpage call path?
>
> Most I/O devices will do DMA to the page in question and thus the kernel
> hasn't written to it and the CPU won't have the data in cache. For the
> few devices which can't do DMA, it's the responsibility of the device
> driver to call flush_dcache_page() (or some other flushing primitive).
Hmm.. Now I am confusing.
If devicer driver or with DMA makes sure cache consistency,
Why filesystem code have to handle it ?
> See the gdth driver for an example:
>
> address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
> memcpy(address, buffer, cpnow);
> flush_dcache_page(sg_page(sl));
> kunmap_atomic(address, KM_BIO_SRC_IRQ);
>
> --
> Matthew Wilcox Intel Open Source Technology Centre
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours. We can't possibly take such
> a retrograde step."
--
Kinds regards,
MinChan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 6:08 ` MinChan Kim
@ 2009-01-16 6:13 ` Nick Piggin
-1 siblings, 0 replies; 22+ messages in thread
From: Nick Piggin @ 2009-01-16 6:13 UTC (permalink / raw)
To: MinChan Kim; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 03:08:30PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> > Most I/O devices will do DMA to the page in question and thus the kernel
> > hasn't written to it and the CPU won't have the data in cache. For the
> > few devices which can't do DMA, it's the responsibility of the device
> > driver to call flush_dcache_page() (or some other flushing primitive).
>
> Hmm.. Now I am confusing.
> If devicer driver or with DMA makes sure cache consistency,
> Why filesystem code have to handle it ?
Because the filesystem is accessing the page directly rathe rthan going to
IO.
Basically, whoever reads or writes the page is responsible to avoid user
aliases. You see these calls in the VM for anonymous pages, in bounce
buffer layers, in filesystems that read or write from pages that are
exposed to userspace (ie. metadata generally need not be flushed because
it will not be mmapped by userspace).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 6:13 ` Nick Piggin
0 siblings, 0 replies; 22+ messages in thread
From: Nick Piggin @ 2009-01-16 6:13 UTC (permalink / raw)
To: MinChan Kim; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 03:08:30PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> > Most I/O devices will do DMA to the page in question and thus the kernel
> > hasn't written to it and the CPU won't have the data in cache. For the
> > few devices which can't do DMA, it's the responsibility of the device
> > driver to call flush_dcache_page() (or some other flushing primitive).
>
> Hmm.. Now I am confusing.
> If devicer driver or with DMA makes sure cache consistency,
> Why filesystem code have to handle it ?
Because the filesystem is accessing the page directly rathe rthan going to
IO.
Basically, whoever reads or writes the page is responsible to avoid user
aliases. You see these calls in the VM for anonymous pages, in bounce
buffer layers, in filesystems that read or write from pages that are
exposed to userspace (ie. metadata generally need not be flushed because
it will not be mmapped by userspace).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 6:13 ` Nick Piggin
@ 2009-01-16 6:16 ` MinChan Kim
-1 siblings, 0 replies; 22+ messages in thread
From: MinChan Kim @ 2009-01-16 6:16 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 07:13:41AM +0100, Nick Piggin wrote:
> On Fri, Jan 16, 2009 at 03:08:30PM +0900, MinChan Kim wrote:
> > On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> > > Most I/O devices will do DMA to the page in question and thus the kernel
> > > hasn't written to it and the CPU won't have the data in cache. For the
> > > few devices which can't do DMA, it's the responsibility of the device
> > > driver to call flush_dcache_page() (or some other flushing primitive).
> >
> > Hmm.. Now I am confusing.
> > If devicer driver or with DMA makes sure cache consistency,
> > Why filesystem code have to handle it ?
>
> Because the filesystem is accessing the page directly rathe rthan going to
> IO.
>
> Basically, whoever reads or writes the page is responsible to avoid user
> aliases. You see these calls in the VM for anonymous pages, in bounce
> buffer layers, in filesystems that read or write from pages that are
> exposed to userspace (ie. metadata generally need not be flushed because
> it will not be mmapped by userspace).
Totally, understand.
Thanks for kind answering to my poor question in patience.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 6:16 ` MinChan Kim
0 siblings, 0 replies; 22+ messages in thread
From: MinChan Kim @ 2009-01-16 6:16 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 07:13:41AM +0100, Nick Piggin wrote:
> On Fri, Jan 16, 2009 at 03:08:30PM +0900, MinChan Kim wrote:
> > On Thu, Jan 15, 2009 at 10:57:30PM -0700, Matthew Wilcox wrote:
> > > Most I/O devices will do DMA to the page in question and thus the kernel
> > > hasn't written to it and the CPU won't have the data in cache. For the
> > > few devices which can't do DMA, it's the responsibility of the device
> > > driver to call flush_dcache_page() (or some other flushing primitive).
> >
> > Hmm.. Now I am confusing.
> > If devicer driver or with DMA makes sure cache consistency,
> > Why filesystem code have to handle it ?
>
> Because the filesystem is accessing the page directly rathe rthan going to
> IO.
>
> Basically, whoever reads or writes the page is responsible to avoid user
> aliases. You see these calls in the VM for anonymous pages, in bounce
> buffer layers, in filesystems that read or write from pages that are
> exposed to userspace (ie. metadata generally need not be flushed because
> it will not be mmapped by userspace).
Totally, understand.
Thanks for kind answering to my poor question in patience.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 5:51 ` MinChan Kim
@ 2009-01-16 5:59 ` Nick Piggin
-1 siblings, 0 replies; 22+ messages in thread
From: Nick Piggin @ 2009-01-16 5:59 UTC (permalink / raw)
To: MinChan Kim; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 16, 2009 at 02:28:04PM +0900, MinChan Kim wrote:
> > > Now, Anyone don't maintain cramfs.
> > > I don't know who is maintain romfs. so I send this patch to linux-mm,
> > > lkml, linux-dev.
> > >
> > > I am not sure my thought is right.
> > >
> > > When readpage is called, page with argument in readpage is just new
> > > allocated because kernel can't find that page in page cache.
> > >
> > > At this time, any user process can't map the page to their address space.
> > > so, I think D-cache aliasing probelm never occur.
> > >
> > > It make sense ?
> >
> > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > when the kernel is going to read some data that userspace wrote, *and*
> > when userspace is going to read some data that the kernel wrote. From a
> > quick look at the patch, this seems to be the second case. The kernel
> > wrote data to a pagecache page, and userspace should be able to read it.
> >
> > To understand why this is necessary, consider a processor which is
> > virtually indexed and has a writeback cache. The kernel writes to a
> > page, then a user process reads from the same page through a different
> > address. The cache doesn't find the data the kernel wrote because it
> > has a different virtual index, so userspace reads stale data.
>
> I see. :)
>
> Thanks for quick reponse and good explaination.
> Hmm,.. one more question.
>
> I can't find flush_dcache_page call in mpage_readpage which is
> generic read function. In case of ext fs, it use mpage_readpage
> with readpage.
>
> who and where call flush_dcache_page in mpage_readpage call path?
I think if the page is populated via IO, then it is responsibility of the
IO layers (eg dma API) to ensure caches are consistent. Presumably this
would include calling flush_dcache_page if we CPU is being used for
the copies (eg. see drivers/block/brd.c).
But there are quite possibly holes around here because not as much testing
is done on CPUs with these kinds of caches. Eg. brd probably should be
doing a flush_dcache_page in the rw == WRITE direction AFAIKS, so it picks
up user aliases here.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 5:59 ` Nick Piggin
0 siblings, 0 replies; 22+ messages in thread
From: Nick Piggin @ 2009-01-16 5:59 UTC (permalink / raw)
To: MinChan Kim; +Cc: Matthew Wilcox, linux-kernel, linux-mm, linux-fsdevel, akpm
On Fri, Jan 16, 2009 at 02:51:19PM +0900, MinChan Kim wrote:
> On Thu, Jan 15, 2009 at 10:33:38PM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 16, 2009 at 02:28:04PM +0900, MinChan Kim wrote:
> > > Now, Anyone don't maintain cramfs.
> > > I don't know who is maintain romfs. so I send this patch to linux-mm,
> > > lkml, linux-dev.
> > >
> > > I am not sure my thought is right.
> > >
> > > When readpage is called, page with argument in readpage is just new
> > > allocated because kernel can't find that page in page cache.
> > >
> > > At this time, any user process can't map the page to their address space.
> > > so, I think D-cache aliasing probelm never occur.
> > >
> > > It make sense ?
> >
> > Sorry, no. You have to call fluch_dcache_page() in two situations --
> > when the kernel is going to read some data that userspace wrote, *and*
> > when userspace is going to read some data that the kernel wrote. From a
> > quick look at the patch, this seems to be the second case. The kernel
> > wrote data to a pagecache page, and userspace should be able to read it.
> >
> > To understand why this is necessary, consider a processor which is
> > virtually indexed and has a writeback cache. The kernel writes to a
> > page, then a user process reads from the same page through a different
> > address. The cache doesn't find the data the kernel wrote because it
> > has a different virtual index, so userspace reads stale data.
>
> I see. :)
>
> Thanks for quick reponse and good explaination.
> Hmm,.. one more question.
>
> I can't find flush_dcache_page call in mpage_readpage which is
> generic read function. In case of ext fs, it use mpage_readpage
> with readpage.
>
> who and where call flush_dcache_page in mpage_readpage call path?
I think if the page is populated via IO, then it is responsibility of the
IO layers (eg dma API) to ensure caches are consistent. Presumably this
would include calling flush_dcache_page if we CPU is being used for
the copies (eg. see drivers/block/brd.c).
But there are quite possibly holes around here because not as much testing
is done on CPUs with these kinds of caches. Eg. brd probably should be
doing a flush_dcache_page in the rw == WRITE direction AFAIKS, so it picks
up user aliases here.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 5:59 ` Nick Piggin
@ 2009-01-16 6:01 ` Matthew Wilcox
-1 siblings, 0 replies; 22+ messages in thread
From: Matthew Wilcox @ 2009-01-16 6:01 UTC (permalink / raw)
To: Nick Piggin
Cc: MinChan Kim, linux-kernel, linux-mm, linux-fsdevel, akpm,
linux-parisc
On Fri, Jan 16, 2009 at 06:59:27AM +0100, Nick Piggin wrote:
> But there are quite possibly holes around here because not as much testing
> is done on CPUs with these kinds of caches. Eg. brd probably should be
> doing a flush_dcache_page in the rw == WRITE direction AFAIKS, so it picks
> up user aliases here.
Nick, if you wanted me to schlep a parisc machine to LCA for you, you
needed to ask me *before* I got as far as Vancouver ;-)
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
@ 2009-01-16 6:01 ` Matthew Wilcox
0 siblings, 0 replies; 22+ messages in thread
From: Matthew Wilcox @ 2009-01-16 6:01 UTC (permalink / raw)
To: Nick Piggin
Cc: MinChan Kim, linux-kernel, linux-mm, linux-fsdevel, akpm,
linux-parisc
On Fri, Jan 16, 2009 at 06:59:27AM +0100, Nick Piggin wrote:
> But there are quite possibly holes around here because not as much testing
> is done on CPUs with these kinds of caches. Eg. brd probably should be
> doing a flush_dcache_page in the rw == WRITE direction AFAIKS, so it picks
> up user aliases here.
Nick, if you wanted me to schlep a parisc machine to LCA for you, you
needed to ask me *before* I got as far as Vancouver ;-)
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 6:01 ` Matthew Wilcox
(?)
@ 2009-01-16 7:34 ` Nick Piggin
2009-01-16 14:28 ` James Bottomley
-1 siblings, 1 reply; 22+ messages in thread
From: Nick Piggin @ 2009-01-16 7:34 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-parisc
On Thu, Jan 15, 2009 at 11:01:24PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 16, 2009 at 06:59:27AM +0100, Nick Piggin wrote:
> > But there are quite possibly holes around here because not as much testing
> > is done on CPUs with these kinds of caches. Eg. brd probably should be
> > doing a flush_dcache_page in the rw == WRITE direction AFAIKS, so it picks
> > up user aliases here.
>
> Nick, if you wanted me to schlep a parisc machine to LCA for you, you
> needed to ask me *before* I got as far as Vancouver ;-)
;)
That actually might not be a bad idea if I had access to one of your crazy
systems. Would it really fit on an aeroplane or would you need a shipping
container? :)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 7:34 ` Nick Piggin
@ 2009-01-16 14:28 ` James Bottomley
2009-01-16 16:28 ` Kyle McMartin
2009-01-16 17:34 ` Grant Grundler
0 siblings, 2 replies; 22+ messages in thread
From: James Bottomley @ 2009-01-16 14:28 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matthew Wilcox, linux-parisc
On Fri, 2009-01-16 at 08:34 +0100, Nick Piggin wrote:
> On Thu, Jan 15, 2009 at 11:01:24PM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 16, 2009 at 06:59:27AM +0100, Nick Piggin wrote:
> > > But there are quite possibly holes around here because not as muc=
h testing
> > > is done on CPUs with these kinds of caches. Eg. brd probably shou=
ld be
> > > doing a flush_dcache_page in the rw =3D=3D WRITE direction AFAIKS=
, so it picks
> > > up user aliases here.
> >=20
> > Nick, if you wanted me to schlep a parisc machine to LCA for you, y=
ou
> > needed to ask me *before* I got as far as Vancouver ;-)
>=20
> ;)
>=20
> That actually might not be a bad idea if I had access to one of your =
crazy
> systems. Would it really fit on an aeroplane or would you need a ship=
ping
> container? :)
They can be taken as checked luggage ... however, what Matthew means is
that by being in Vancouver he's already in transit to Australia.
However, we can give you access to the several remote test rings we
have, either Cupertino (send ssh key to Rick Jones <raj@netperf.org> or
Thiabut Var=C3=A8ne <varenet@parisc-linux.org>)
I thought we also had a wiki page listing all the machines, but I can't
find it. They all use the HP Guardian Service Processor console, which
gives you remote console, power and all the other good things you need.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 14:28 ` James Bottomley
@ 2009-01-16 16:28 ` Kyle McMartin
2009-01-16 17:34 ` Grant Grundler
1 sibling, 0 replies; 22+ messages in thread
From: Kyle McMartin @ 2009-01-16 16:28 UTC (permalink / raw)
To: James Bottomley; +Cc: Nick Piggin, Matthew Wilcox, linux-parisc
On Fri, Jan 16, 2009 at 09:28:21AM -0500, James Bottomley wrote:
> On Fri, 2009-01-16 at 08:34 +0100, Nick Piggin wrote:
> > On Thu, Jan 15, 2009 at 11:01:24PM -0700, Matthew Wilcox wrote:
> > > On Fri, Jan 16, 2009 at 06:59:27AM +0100, Nick Piggin wrote:
> > > > But there are quite possibly holes around here because not as m=
uch testing
> > > > is done on CPUs with these kinds of caches. Eg. brd probably sh=
ould be
> > > > doing a flush_dcache_page in the rw =3D=3D WRITE direction AFAI=
KS, so it picks
> > > > up user aliases here.
> > >=20
> > > Nick, if you wanted me to schlep a parisc machine to LCA for you,=
you
> > > needed to ask me *before* I got as far as Vancouver ;-)
> >=20
> > ;)
> >=20
> > That actually might not be a bad idea if I had access to one of you=
r crazy
> > systems. Would it really fit on an aeroplane or would you need a sh=
ipping
> > container? :)
>=20
> They can be taken as checked luggage ... however, what Matthew means =
is
> that by being in Vancouver he's already in transit to Australia.
> However, we can give you access to the several remote test rings we
> have, either Cupertino (send ssh key to Rick Jones <raj@netperf.org> =
or
> Thiabut Var=E8ne <varenet@parisc-linux.org>)
>=20
I think Nick already has access to the gsyprf* systems, as I've seen hi=
m
logged in there before. ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Remove needless flush_dcache_page call
2009-01-16 14:28 ` James Bottomley
2009-01-16 16:28 ` Kyle McMartin
@ 2009-01-16 17:34 ` Grant Grundler
1 sibling, 0 replies; 22+ messages in thread
From: Grant Grundler @ 2009-01-16 17:34 UTC (permalink / raw)
To: James Bottomley; +Cc: Nick Piggin, Matthew Wilcox, linux-parisc
On Fri, Jan 16, 2009 at 09:28:21AM -0500, James Bottomley wrote:
...`
> They can be taken as checked luggage ... however, what Matthew means is
> that by being in Vancouver he's already in transit to Australia.
> However, we can give you access to the several remote test rings we
> have, either Cupertino (send ssh key to Rick Jones <raj@netperf.org> or
> Thiabut Var??ne <varenet@parisc-linux.org>)
Rick just gets me physical access when we have time to mess with the rack.
Kyle is correct that Nick still has a login to Cupertino ring though he
might need one of us to update his .ssh/authorized keys:
grundler@lp1000r:~$ finger nick
Login: npiggin Name: Nick Piggin
Directory: /home/npiggin Shell: /bin/bash
Office Phone: +xx x xxxx xxxx
Last login Wed Aug 3 22:35 2005 (PDT) on pts/5 from 203-173-7-11.dyn.iinet.net.au
No mail.
No Plan.
IIRC, i gave him access to a "beefier" ia64 machine at the time (and those are
all still there too).
> I thought we also had a wiki page listing all the machines, but I can't
> find it.
http://www.parisc-linux.org/cluster.html
I've intentionally left it unlinked from the main page.
> They all use the HP Guardian Service Processor console, which
> gives you remote console, power and all the other good things you need.
And most of the parisc machines are in a sorry state right now.
I'll update the web page with current state.
hth,
grant
^ permalink raw reply [flat|nested] 22+ messages in thread