From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
Community Manager <community.manager@xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based on region offsets
Date: Fri, 27 Jun 2025 16:51:46 +0200 [thread overview]
Message-ID: <aF6wAh2VaMc9mYV-@macbook.local> (raw)
In-Reply-To: <475fb02b-0b00-4aab-b73c-9604fe050074@suse.com>
On Thu, Jun 26, 2025 at 09:35:04AM +0200, Jan Beulich wrote:
> On 25.06.2025 18:24, Roger Pau Monné wrote:
> > On Tue, Jun 24, 2025 at 06:16:15PM +0200, Jan Beulich wrote:
> >> On 20.06.2025 13:11, Roger Pau Monne wrote:
> >>> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> >>> +{
> >>> + unsigned long pfn = PFN_DOWN(base);
> >>> +
> >>> + return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
> >>
> >> Aiui for this to be correct, there need to be gaps between the ranges
> >> covered by individual lookup table slots. In the setup logic you have a
> >> check commented "Avoid compression if there's no gain", but that doesn't
> >> look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
> >> appear to)?
> >
> > But if there are no gaps, the full region is covered correctly, and
> > hence it's compressible?
>
> If there's a guarantee that such ranges would be folded into a single one,
> all would be fine.
>
> > Maybe I'm missing something, could you maybe provide an example that
> > would exhibit this issue?
>
> My understanding is that when there's no gap between regions, and when
> [base, base + npages) crosses as region boundary, then the expression
> above will yield true when, because of crossing a region boundary, it
> ought to be false. Or did I simply misunderstand the purpose of the
> pdx_is_region_compressible() invocations?
If there's no gap between the regions it's IMO intended for
pdx_is_region_compressible() to return true, as the whole region is
continuous in both the PFN and PDX spaces, and hence compressible
(even if it spans multiple regions).
But maybe I'm not understanding your point correctly, could you maybe
provide an example if you disagree with my reply above? Sorry if I'm
being dull, with this compression stuff it's sometimes hard for me to
visualize the case you are trying to make without a concrete
example.
Thanks, Roger.
next prev parent reply other threads:[~2025-06-27 14:52 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 11:11 [PATCH v2 0/8] pdx: introduce a new compression algorithm Roger Pau Monne
2025-06-20 11:11 ` [PATCH v2 1/8] x86/pdx: simplify calculation of domain struct allocation boundary Roger Pau Monne
2025-06-24 13:05 ` Jan Beulich
2025-06-25 15:14 ` Roger Pau Monné
2025-06-20 11:11 ` [PATCH v2 2/8] kconfig: turn PDX compression into a choice Roger Pau Monne
2025-06-24 13:13 ` Jan Beulich
2025-06-26 7:49 ` Roger Pau Monné
2025-06-26 12:33 ` Jan Beulich
2025-06-20 11:11 ` [PATCH v2 4/8] pdx: introduce command line compression toggle Roger Pau Monne
2025-06-24 13:40 ` Jan Beulich
2025-06-25 15:46 ` Roger Pau Monné
2025-06-25 16:00 ` Jan Beulich
2025-06-25 17:45 ` Roger Pau Monné
2025-06-26 6:17 ` Jan Beulich
2025-06-20 11:11 ` [PATCH v2 5/8] pdx: allow per-arch optimization of PDX conversion helpers Roger Pau Monne
2025-06-24 13:51 ` Jan Beulich
2025-06-25 15:51 ` Roger Pau Monné
2025-06-25 16:04 ` Jan Beulich
2025-06-20 11:11 ` [PATCH v2 6/8] test/pdx: add PDX compression unit tests Roger Pau Monne
2025-06-24 13:37 ` Anthony PERARD
2025-06-25 15:55 ` Roger Pau Monné
2025-06-20 11:11 ` [PATCH v2 7/8] pdx: move some helpers in preparation for new compression Roger Pau Monne
2025-06-24 13:52 ` Jan Beulich
2025-06-20 11:11 ` [PATCH v2 8/8] pdx: introduce a new compression algorithm based on region offsets Roger Pau Monne
2025-06-24 16:16 ` Jan Beulich
2025-06-25 16:24 ` Roger Pau Monné
2025-06-26 7:35 ` Jan Beulich
2025-06-27 14:51 ` Roger Pau Monné [this message]
2025-06-29 14:36 ` Jan Beulich
2025-07-01 7:26 ` Roger Pau Monné
2025-06-30 6:34 ` Jan Beulich
2025-07-01 15:49 ` Roger Pau Monné
2025-07-01 16:01 ` Jan Beulich
[not found] ` <20250620111130.29057-4-roger.pau@citrix.com>
2025-06-24 13:32 ` [PATCH v2 3/8] pdx: provide a unified set of unit functions Jan Beulich
2025-06-25 15:32 ` Roger Pau Monné
2025-06-28 2:08 ` [PATCH v2 0/8] pdx: introduce a new compression algorithm Stefano Stabellini
2025-06-30 15:02 ` Roger Pau Monné
2025-07-01 1:50 ` Stefano Stabellini
2025-07-01 3:33 ` Stefano Stabellini
2025-07-01 6:05 ` Jan Beulich
2025-07-01 20:46 ` Stefano Stabellini
2025-07-02 6:08 ` Jan Beulich
2025-07-02 6:32 ` Jan Beulich
2025-07-02 6:53 ` Roger Pau Monné
2025-07-02 7:00 ` Roger Pau Monné
2025-07-02 7:52 ` Orzel, Michal
2025-07-02 8:26 ` Roger Pau Monné
2025-07-02 8:49 ` Julien Grall
2025-07-02 8:54 ` Orzel, Michal
2025-07-02 9:45 ` Roger Pau Monné
2025-07-03 0:22 ` Stefano Stabellini
2025-07-03 0:19 ` Stefano Stabellini
2025-07-02 8:45 ` Julien Grall
2025-07-03 8:42 ` Roger Pau Monné
2025-07-03 18:04 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aF6wAh2VaMc9mYV-@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=community.manager@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.