On Fri, Sep 27, 2024 at 9:51 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Fri, Sep 27, 2024 at 07:57:49PM -0700, Yosry Ahmed wrote: > > On Fri, Sep 27, 2024 at 7:16 PM Kanchana P Sridhar > > <kanchana.p.sridhar@xxxxxxxxx> wrote: > > > > > > For zswap_store() to support large folios, we need to be able to do > > > a batch update of zswap_stored_pages upon successful store of all pages > > > in the folio. For this, we need to add folio_nr_pages(), which returns > > > a long, to zswap_stored_pages. > > > > Do we really need this? A lot of places in the kernel assign the > > result of folio_nr_pages() to an int (thp_nr_pages(), > > split_huge_pages_all(), etc). I don't think we need to worry about > > folio_nr_pages() exceeding INT_MAX for a while. > > You'd be surprised. Let's assume we add support for PUD-sized pages > (personally I think this is too large to make sense, but some people can't > be told). On arm64, we can have a 64kB page size, so that's 13 bits per > level for a total of 2^26 pages per PUD. That feels uncomfortable close > to 2^32 to me. > > Anywhere you've found that's using an int to store folio_nr_pages() is > somewhere we should probably switch to long. There are a lot of them: rmap.c, shmem.c, khugepaged.c, etc. > And this, btw, is why I've > moved from using an int to store folio_size() to using size_t. A PMD is > already 512MB (with a 64KB page size), and so a PUD will be 4TB. Thanks for pointing this out. I assumed the presence of many places using int to store folio_nr_pages() means that it's a general assumption. Also, if we think it's possible that a single folio size may approach INT_MAX, then we are in bigger trouble for zswap_stored_pages, because that's the total number of pages stored in zswap on the entire system. That's much more likely to exceed INT_MAX than a single folio. > > thp_nr_pages() is not a good example. I'll be happy when we kill it; > we're actually almost there. Yeah I can only see 2 callers.
