Re: Fwd: Re: flush_cache_page()
On Sat, 29 Jan 2005 11:37:08 + Russell King <[EMAIL PROTECTED]> wrote: > Thanks for the response. However, apart from Ralph, Paul and yourself, > it seems none of the other architecture maintainers care about this > patch - the original mail was BCC'd to the architecture list. Maybe > that's an implicit acceptance of this patch, I don't know. I haven't responded because I simply have no objections to your patch. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: flush_cache_page()
On Sat, Jan 29, 2005 at 08:29:22AM -0600, James Bottomley wrote: > On Sat, 2005-01-29 at 11:37 +, Russell King wrote: > > Thanks for the response. However, apart from Ralph, Paul and yourself, Who are you talking about ;-) > > it seems none of the other architecture maintainers care about this > > patch - the original mail was BCC'd to the architecture list. Maybe > > that's an implicit acceptance of this patch, I don't know. > > Well, OK, I'll try to answer for parisc, since we have huge VIPT > aliasing caches as well. > > Right now, we have a scheme in flush_cache_page to make sure it's only > called when necessary (cache flushes are expensive for us and show up as > the primary cpu consumer in all of our profiles). Our scheme is to see > if a translation exists for the page and skip the flush if it doesn't. > > Obviously, like MIPS, we're also walking the page tables without > locking... VIPT caches on MIPS R4000-class processors will perform an address translation using the TLB to obtain the physical address that will be compared against the cache tags. This may result in TLB reloads which are an ugly case to deal with if the flush is being performed for a mm other than current->mm. Since a long time the flush_cache_page implementation assumes getting this right is too hard but I suppose it's an optimization that should be attempted and which would require pagetable lookups. The current implementation actually does lookups as an optimization (and I'm just asking myself if that is still correct) by looking at the present bit of the pte to deciede if data from that page may have entered the cache at all so we can avoid the flush entirely. > Looking at the callers of this, it seems it would be very unlikely to > call this with a missing translation, in that case, we can use the pfn > to flush the page through a temporary alias space instead and just take > the odd hit if no translation exists. That would be the MIPS optimization for the case of flushing on behalf of another process. Ralf PS: Don't get me started on PIVT caches ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: flush_cache_page()
On Sat, 2005-01-29 at 11:37 +, Russell King wrote: > Thanks for the response. However, apart from Ralph, Paul and yourself, > it seems none of the other architecture maintainers care about this > patch - the original mail was BCC'd to the architecture list. Maybe > that's an implicit acceptance of this patch, I don't know. Well, OK, I'll try to answer for parisc, since we have huge VIPT aliasing caches as well. Right now, we have a scheme in flush_cache_page to make sure it's only called when necessary (cache flushes are expensive for us and show up as the primary cpu consumer in all of our profiles). Our scheme is to see if a translation exists for the page and skip the flush if it doesn't. Obviously, like MIPS, we're also walking the page tables without locking... Looking at the callers of this, it seems it would be very unlikely to call this with a missing translation, in that case, we can use the pfn to flush the page through a temporary alias space instead and just take the odd hit if no translation exists. > In other words, unless I actually receive some real help from the other > architecture maintainers on this to address your concerns, ARM version 6 > CPUs with aliasing L1 caches (== >16K) will remain a dead dodo with > mainline Linux kernels. I've probably been told and forgotten, but what problems do you have with your VIPT (Arm 6 is VIPT, not VIVT, right?) cache >16k which we don't have with our 4MB VIPT caches on pa (which work, but cause us grief with enormous amounts of flushing)? James
Re: Fwd: Re: flush_cache_page()
On Tue, Jan 11, 2005 at 04:07:09PM -0800, Linus Torvalds wrote: > On Tue, 11 Jan 2005, Russell King wrote: > > Any responses on this? Didn't get any last time I mailed this out. > > I don't have any real objections. I'd like it verified that gcc can > compile away all the overhead on the architectures that don't use the pfn, > since "page_to_pfn()" can be a bit expensive otherwise.. But I don't see > anything wrong with the approach. Thanks for the response. However, apart from Ralph, Paul and yourself, it seems none of the other architecture maintainers care about this patch - the original mail was BCC'd to the architecture list. Maybe that's an implicit acceptance of this patch, I don't know. I do know that page_to_pfn() will generate code on some platforms which don't require it due to them declaring flush_cache_page() as a function. However, I assert that if they don't need this overhead, that's for them to fix up. I don't know all their quirks so it isn't something I can tackle. In other words, unless I actually receive some real help from the other architecture maintainers on this to address your concerns, ARM version 6 CPUs with aliasing L1 caches (== >16K) will remain a dead dodo with mainline Linux kernels. (This mail BCC'd to the architecture list again in the vain hope that someone will offer assistance.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core
Re: Fwd: Re: flush_cache_page()
On Tue, Jan 11, 2005 at 04:07:09PM -0800, Linus Torvalds wrote: On Tue, 11 Jan 2005, Russell King wrote: Any responses on this? Didn't get any last time I mailed this out. I don't have any real objections. I'd like it verified that gcc can compile away all the overhead on the architectures that don't use the pfn, since page_to_pfn() can be a bit expensive otherwise.. But I don't see anything wrong with the approach. Thanks for the response. However, apart from Ralph, Paul and yourself, it seems none of the other architecture maintainers care about this patch - the original mail was BCC'd to the architecture list. Maybe that's an implicit acceptance of this patch, I don't know. I do know that page_to_pfn() will generate code on some platforms which don't require it due to them declaring flush_cache_page() as a function. However, I assert that if they don't need this overhead, that's for them to fix up. I don't know all their quirks so it isn't something I can tackle. In other words, unless I actually receive some real help from the other architecture maintainers on this to address your concerns, ARM version 6 CPUs with aliasing L1 caches (== 16K) will remain a dead dodo with mainline Linux kernels. (This mail BCC'd to the architecture list again in the vain hope that someone will offer assistance.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core
Re: Fwd: Re: flush_cache_page()
On Sat, 2005-01-29 at 11:37 +, Russell King wrote: Thanks for the response. However, apart from Ralph, Paul and yourself, it seems none of the other architecture maintainers care about this patch - the original mail was BCC'd to the architecture list. Maybe that's an implicit acceptance of this patch, I don't know. Well, OK, I'll try to answer for parisc, since we have huge VIPT aliasing caches as well. Right now, we have a scheme in flush_cache_page to make sure it's only called when necessary (cache flushes are expensive for us and show up as the primary cpu consumer in all of our profiles). Our scheme is to see if a translation exists for the page and skip the flush if it doesn't. Obviously, like MIPS, we're also walking the page tables without locking... Looking at the callers of this, it seems it would be very unlikely to call this with a missing translation, in that case, we can use the pfn to flush the page through a temporary alias space instead and just take the odd hit if no translation exists. In other words, unless I actually receive some real help from the other architecture maintainers on this to address your concerns, ARM version 6 CPUs with aliasing L1 caches (== 16K) will remain a dead dodo with mainline Linux kernels. I've probably been told and forgotten, but what problems do you have with your VIPT (Arm 6 is VIPT, not VIVT, right?) cache 16k which we don't have with our 4MB VIPT caches on pa (which work, but cause us grief with enormous amounts of flushing)? James
Re: Fwd: Re: flush_cache_page()
On Sat, Jan 29, 2005 at 08:29:22AM -0600, James Bottomley wrote: On Sat, 2005-01-29 at 11:37 +, Russell King wrote: Thanks for the response. However, apart from Ralph, Paul and yourself, Who are you talking about ;-) it seems none of the other architecture maintainers care about this patch - the original mail was BCC'd to the architecture list. Maybe that's an implicit acceptance of this patch, I don't know. Well, OK, I'll try to answer for parisc, since we have huge VIPT aliasing caches as well. Right now, we have a scheme in flush_cache_page to make sure it's only called when necessary (cache flushes are expensive for us and show up as the primary cpu consumer in all of our profiles). Our scheme is to see if a translation exists for the page and skip the flush if it doesn't. Obviously, like MIPS, we're also walking the page tables without locking... VIPT caches on MIPS R4000-class processors will perform an address translation using the TLB to obtain the physical address that will be compared against the cache tags. This may result in TLB reloads which are an ugly case to deal with if the flush is being performed for a mm other than current-mm. Since a long time the flush_cache_page implementation assumes getting this right is too hard but I suppose it's an optimization that should be attempted and which would require pagetable lookups. The current implementation actually does lookups as an optimization (and I'm just asking myself if that is still correct) by looking at the present bit of the pte to deciede if data from that page may have entered the cache at all so we can avoid the flush entirely. Looking at the callers of this, it seems it would be very unlikely to call this with a missing translation, in that case, we can use the pfn to flush the page through a temporary alias space instead and just take the odd hit if no translation exists. That would be the MIPS optimization for the case of flushing on behalf of another process. Ralf PS: Don't get me started on PIVT caches ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: flush_cache_page()
On Tue, Jan 11, 2005 at 10:36:52PM +, Russell King wrote: > However, since it's been rather a long time, I will need to go > back and redo this patch, along with all the other patches which > get ARMv6 VIPT aliasing caches working, and then confirm that this > does indeed end up with something which works. > > I just don't want to go chasing my tail on something which essentially > is unacceptable. > A bit late entering this thread (I didn't see it initially), but.. Having the pfn available would be welcome for the SH-4 VIPT and sh64 cases at least (or most likely any VIPT L1 for that matter), for the same reasons that have already been noted.. pgpwB31iKpqIP.pgp Description: PGP signature
Re: Fwd: Re: flush_cache_page()
On Tue, Jan 11, 2005 at 10:36:52PM +, Russell King wrote: However, since it's been rather a long time, I will need to go back and redo this patch, along with all the other patches which get ARMv6 VIPT aliasing caches working, and then confirm that this does indeed end up with something which works. I just don't want to go chasing my tail on something which essentially is unacceptable. A bit late entering this thread (I didn't see it initially), but.. Having the pfn available would be welcome for the SH-4 VIPT and sh64 cases at least (or most likely any VIPT L1 for that matter), for the same reasons that have already been noted.. pgpwB31iKpqIP.pgp Description: PGP signature
