On Fri, 6 Apr 2018, Alexey Dobriyan wrote: > > > Its not so simple. Please verify that the edge cases of all object size / > > > alignment etc calculations are doable with 32 bit entities first. > > > > > > And size_t makes sense as a parameter. > > > > Alexey, please don't let this stuff dangle on. > > > > I think I'll merge this as-is but some fixups might be needed as a > > result of Christoph's suggestion? > > I see this email in public archives, but not in my mailbox :-\ Oh gosh. More email trouble with routing via comcast. > 1) > "int size" proves that 4GB+ caches were always broken both on SLUB > and SLAB. I could audit calculate_sizes() and friends but why bother > if create_cache() already truncated everything. The problem is that intermediate results in calculations may exceed the int range. Please look at that. > You're writing: > > that the edge cases of all object size ... > ... are doable with 32 bit entities > > AS IF they were doable with 64-bit. They weren't. That was not the issue. No one ever claimed that slabs of more than 4GB were supported. > kmalloc is limited to 64MB, after that it fallbacks to page allocator. > Which means that some huge structure cache must be created by cache or > not affected by conversion as it still falls back to page allocator. That is not accurate: kmalloc falls back after PAGE_SIZE << 1 to the page allocator. > > And size_t makes sense as a parameter. > > size_t doesn't make sense for kernel as 4GB+ objects are few and far > between. Again not the issue. Please stop fighting straw men and issues that you come up with in your imagination. size_t makes sense because the type is designed to represent the size of an object.
