Re: [PATCH v2 0/7] Kernel huge I/O mapping support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2015-02-24 at 09:09 +0100, Ingo Molnar wrote:
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > <reads the code>
> > 
> > Oh.  We don't do any checking at all.  We're just telling 
> > userspace programmers "don't do that".  hrm.  What are 
> > your thoughts on adding the overlap checks to the kernel?
> 
> I have requested such sanity checking in previous review as 
> well, it has to be made fool-proof for this optimization to 
> be usable.
> 
> Another alternative would be to make this not a transparent 
> optimization, but a separate API: ioremap_hugepage() or so.
> 
> The devices and drivers dealing with GBs of remapped pages 
> is still relatively low, so they could make explicit use of 
> the API and opt in to it.
> 
> What I was arguing against was to make it a CONFIG_ option: 
> that achieves very little in practice, such APIs should be 
> uniformly available.

I was able to come up with simple changes that fall back to 4KB mappings
when a target range is covered by MTRRs.  So, with the changes, it is
now safe to enable huge page mappings to ioremap() transparently without
such restriction.  I will post updated patchset hopefully soon.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]