Messages in this thread | | | Date | Tue, 17 May 2022 15:46:55 -0700 | From | Ira Weiny <> | Subject | Re: [PATCH V10 33/44] kmap: Make kmap work for devmap protected pages |
| |
On Wed, May 11, 2022 at 06:25:19PM -0700, Ira wrote: > On Thu, Apr 28, 2022 at 08:50:34AM -0700, Christoph Hellwig wrote: > > On Tue, Apr 19, 2022 at 10:06:38AM -0700, ira.weiny@intel.com wrote: > > > index a77be5630209..32ed07c2994b 100644 > > > --- a/include/linux/highmem-internal.h > > > +++ b/include/linux/highmem-internal.h > > > @@ -151,6 +151,8 @@ static inline void totalhigh_pages_add(long count) > > > > > > #else /* CONFIG_HIGHMEM */ > > > > > > +#include <linux/memremap.h> > > > > Uuuh, I'd really prefer to avoid having to pull in memremap.h into > > basically the whole kernel build. > > > > Fair enough. What should I call a header to store the new pgmap_set_*() calls? > > devmap_prot.h > > ? > > Or I could just add the calls into highmem-internal.h. That might be more > appropriate given the new direction of that interface. > > I think I'm leaning toward that vs adding another header.
Ok there is a trade off here which I'm not sure is a good idea.
In order to make kmap faster I carefully placed the devmap_protected() call completely inline.[1] This specifically checks the PGMAP_PROTECTION flag in dev_pagemap.[1]
I see only 2 ways of not including memremap.h in highmem-internal.h.
1) Make this check a function call and place it in memremap.c 2) Move struct dev_pagemap (and it's dependencies) to another header.
Number 2 negates any positive effect of splitting the header file.
Number 1 is going to force some overhead on all ZONE_DEVICE pages if PMEM is in the system.
Do you think the extra run time overhead is a reasonable trade off to eliminating the header?
Ira
[1] https://lore.kernel.org/lkml/20220419170649.1022246-29-ira.weiny@intel.com/
| |