| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20100204043923.GC451@linux-sh.org> Date: Thu, 4 Feb 2010 13:39:23 +0900 From: Paul Mundt <lethal@...ux-sh.org> To: George Spelvin <linux@...izon.com> Cc: catalin.marinas@....com, linux-kernel@...r.kernel.org Subject: Re: USB mass storage and ARM cache coherency On Wed, Feb 03, 2010 at 06:56:44PM -0500, George Spelvin wrote: > > Apart from that, flush_dcache_page() doesn't have any data flow > > information. Optimisations could be done on ARM if we know that the > > kernel only intends to read from a page (no flushing necessary with a > > non-aliasing D-cache). > > Already done in flush_dcache_page(). If possible (uniprocessor), it just > flags the page as PG_dcache_dirty, and defers the actual flush operation > until it's mapped somewhere else (either a virtual alias or executable). > Try reading the thread again, as you seem to have missed the point completely. The issue isn't with lazy dcache writeback, the issue is that flush_dcache_page() is a bit of a sledgehammer for cases when directional information is available. The DMA mapping operations conversely are aware of data flow and optimize accordingly. Additionally, with something like a flush_dcache_range() it's possible to optimize for large ranges as opposed to page-at-a-time looping for anything that needs to flag PG_dcache_dirty on a bulk group of pages. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists