Page MenuHomeFreeBSD

LinuxKPI: move __kmalloc from slab.h to slab.c
ClosedPublic

Authored by bz on Jun 30 2024, 8:49 PM.
Tags
None
Referenced Files
F98034464: D45815.diff
Wed, Oct 2, 2:29 AM
Unknown Object (File)
Sat, Sep 28, 3:33 PM
Unknown Object (File)
Mon, Sep 23, 4:42 AM
Unknown Object (File)
Sun, Sep 22, 8:01 AM
Unknown Object (File)
Fri, Sep 20, 6:02 PM
Unknown Object (File)
Fri, Sep 20, 6:02 PM
Unknown Object (File)
Fri, Sep 20, 6:02 PM
Unknown Object (File)
Fri, Sep 20, 6:02 PM
Subscribers

Details

Summary

In order to allow the allocator to change in the future move it into
the implementation file from being an inline function in the header.

While here factor out the size calculation and add a comment as-to why
this is done. We will need the size (_s) in the future to make a
decision on how to allocate.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

Test Plan

(I amnually extracted this modulo the extra changes on top
of D45812 as moving it can go independetly upfront).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 58431
Build 55319: arc lint + arc unit

Event Timeline

bz requested review of this revision.Jun 30 2024, 8:49 PM

If no one replies this will go in on Monday.

This revision is now accepted and ready to land.Jul 26 2024, 11:21 AM

Updating for reference after rebase; also changed linuxkpi_ to lkpi_
as per recent discussions until we have a README.

This revision now requires review to proceed.Jul 26 2024, 11:33 AM
This revision is now accepted and ready to land.Jul 26 2024, 11:50 AM
This revision was automatically updated to reflect the committed changes.

I have a stale review comment somewhere I can't find now. But it said something like "I like this change because we do way too much inlining in the linuxkpi because that causes problems with our goal to have a stable ABI on a stable branch"

In D45815#1052042, @imp wrote:

"I like this change because we do way too much inlining in the linuxkpi because that causes problems with our goal to have a stable ABI on a stable branch"

Yeah I'd say any potential performance gain from inlining it pales in comparison to the maintainability improvement from not doing so.