Bug 2059734 - Support for 16KB pages ?
Summary: Support for 16KB pages ?
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-01 20:55 UTC by jmranger
Modified: 2023-04-07 22:37 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-04-07 19:28:06 UTC
Embargoed:
pm-rhel: lvm-technical-solution?
pm-rhel: lvm-test-coverage?


Attachments (Terms of Use)
result to the test asked in comment #5 (15.86 KB, text/plain)
2023-04-07 17:35 UTC, jmranger
no flags Details

Description jmranger 2022-03-01 20:55:34 UTC
AsahiLinux[0] (Linux on Macs with Apple-Silicon processors) is nearing its first release, and the main developer has announced[1] that it will use 16KB pages, since that is what the IOMMUs of that processor expect by default.

While the LVM2 command-line tools work with 16KB pages, they throw warnings[2][3] about a non-standard page size.

Would it be possible to officially support 16KB pages?

Thanks.

[0] https://asahilinux.org/
[1] https://twitter.com/marcan42/status/1498710903675842563
[2] https://sourceware.org/git/?p=lvm2.git;a=blob;f=lib/metadata/metadata.c;h=1cda1888f35698c43a0dbc0ca4d8693730ad9a0f;hb=HEAD#l134
[3] https://sourceware.org/git/?p=lvm2.git;a=blob;f=tools/pvck.c;h=5273da63ca4ea7f527972a392df998dcc88692cb;hb=HEAD#l1150

Comment 2 Hector Martin 2023-01-23 04:24:00 UTC
Just to be clear: 16K *is* a completely standard ARM64 page size (albeit one supported by relatively few SoCs). So it is a bug for LVM2 to treat it as a nonstandard/unexepected page size.

Comment 3 David Teigland 2023-01-23 15:36:44 UTC
Hi, I'd like to include that patch, do you know how we could test it before applying it?

Comment 4 jmranger 2023-04-07 00:32:16 UTC
Apologies for the delay. $life kind of got in the way.

I still have a setup to test this, although I don't use it that much in that configuration. So it depends on the kind of validation you're hoping for. Sanity check? Sure. Thorough burn-in? Probably not. Machine on which you can get a remote access? Sorry - I'm not in a position to offer that, although if that's what you need, it's not necessarily impossible to organize. What did you have in mind?

Obviously, there's nothing I (or the Asahi community as a whole) can test until there's a proposed patch ;-)

Thanks and Regards,

jmranger

Comment 5 David Teigland 2023-04-07 14:10:30 UTC
A sanity check would be fine:

pvcreate /dev/foo
vgcreate test /dev/foo
lvcreate -l1 -n lv1 test
pvs /dev/foo
lvs test/lv1
pvck --dump headers /dev/foo
pvck --dump metadata /dev/foo
vgchange -an test
vgremove -y test

It would be nice to see the output from that sequence of commands.

I've added the patch from comment 1 to this devel branch for you to build and test:
https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-16KB-page-size

Comment 6 jmranger 2023-04-07 17:35:19 UTC
Created attachment 1956259 [details]
result to the test asked in comment #5

Comment 7 jmranger 2023-04-07 17:35:53 UTC
(Not sure why I didn't - and still don't - see the patch as an attachment. Sorry for this.)

Here's the output you requested. Please note that I did it twice, first with the parent commit, then with the patch applied. Please also note that the configured step ended with the following warning, which I ignored:
configure: WARNING: Unrecognized 'vdoformat' tool is REQUIRED for VDO logical volume creation!

Please let me know if there's anyting else I can do.

Regards,

jmranger

Comment 8 David Teigland 2023-04-07 19:28:06 UTC
Thanks, it works.  The patch (with one small addition) in the main branch:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=b443eac6efd29a72a4356f54c713cc9a0e0da866

Comment 9 jmranger 2023-04-07 20:24:56 UTC
I must admit that I fail to understand how both extra changes are related to the 16K support, but if the exercise helped find and fix other issues at the same time, I'm all for it.

Thanks for your help!

Comment 10 David Teigland 2023-04-07 21:05:07 UTC
Thanks for pointing that out, there was an unrelated config.c change that snuck into that commit and I've removed that with another commit.

The addition of:
int mda_num = (mda_offset <= 65536) ? 1 : 2;

fixes the output to display "mda_header_1" instead of "mda_header_2" for non-4k page sizes.

Comment 11 jmranger 2023-04-07 22:37:57 UTC
Both make sense now.

Thanks again.


Note You need to log in before you can comment on or make changes to this bug.