On Wed, Aug 17, 2022 at 10:34:05PM +0100, Matthew Wilcox wrote: > On Wed, Aug 17, 2022 at 01:52:33PM -0700, Ira Weiny wrote: > > On Wed, Aug 17, 2022 at 01:23:41PM -0700, Ira wrote: [snip] > > > How many folios do you think will need to be mapped at a time? And is there > > > any practical limit on their size? Are 64k blocks a reasonable upper bound > > > until highmem can be deprecated completely? > > > > > > I say this because I'm not sure that mapping a 64k block would always fail. > > > These mappings are transitory. How often will a filesystem be mapping more > > > than 2 folios at once? > > > > I did the math wrong but I think my idea can still work. > > The thing is that kmap_local_page() can be called from interrupt context > (how often is it? no idea). So you map two 64kB folios (at 16 entries > each) and that consumes 32 entries for this CPU, now you take an interrupt > and that's 33. I don't know how deep that goes; can we have some mapped > in userspace, some mapped in softirq and then another interrupt causes > more to be mapped in hardirq? I don't really want to find out, so I'd > rather always punt to vmap() for multipage folios. > > Is there a reason you want to make folio_map_local() more efficient > on HIGHMEM systems? It is not about efficiency. It is about making the callers of folio_map_local() not have to worry about the context it is used in. If 64 entries is not enough how many? I'm trying to see if there is any bound we could reasonably establish? Even kmap_local_page() _may_ run out of entries. Ira
