From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: minios-devel@lists.xenproject.org,
xen-devel@lists.xenproject.org, wl@xen.org
Subject: Re: [PATCH 02/10] mini-os: sort and sanitize e820 memory map
Date: Mon, 13 Dec 2021 22:19:07 +0100 [thread overview]
Message-ID: <20211213211907.lbjjnvayklf7qucb@begin> (raw)
In-Reply-To: <ab1b2e26-65c1-c877-cf88-0df50d38b925@suse.com>
Juergen Gross, le lun. 13 déc. 2021 15:56:21 +0100, a ecrit:
> On 12.12.21 01:05, Samuel Thibault wrote:
> > Hello,
> >
> > Juergen Gross, le lun. 06 déc. 2021 08:23:29 +0100, a ecrit:
> > > - align the entries to page boundaries
> >
> > > + /* Adjust map entries to page boundaries. */
> > > + for ( i = 0; i < e820_entries; i++ )
> > > + {
> > > + end = (e820_map[i].addr + e820_map[i].size + PAGE_SIZE - 1) & PAGE_MASK;
> > > + e820_map[i].addr &= PAGE_MASK;
> > > + e820_map[i].size = end - e820_map[i].addr;
> > > + }
> >
> > Mmm, what if the previous entry ends after the aligned start?
> >
> > On real machines that does happen, and you'd rather round up the start
> > address of usable areas, rather than rounding it down (and conversely
> > for the end).
>
> I think you are partially right. :-)
>
> Entries for resources managed by Mini-OS (RAM, maybe NVME?) should be
> rounded to cover only complete pages (start rounded up, end rounded
> down), but all other entries should be rounded to cover the complete
> area (start rounded down, end rounded up) in order not to use any
> partial used page for e.g. mapping foreign pages.
Right!
> > > + /* Sort entries by start address. */
> > > + for ( i = 0; i < e820_entries - 1; i++ )
> > > + {
> > > + if ( e820_map[i].addr > e820_map[i + 1].addr )
> > > + {
> > > + e820_swap_entries(i, i + 1);
> > > + i = -1;
> > > + }
> > > + }
> >
> > This looks O(n^3) to me? A bubble sort like this should be fine:
> >
> > /* Sort entries by start address. */
> > for ( last = e820_entries; last > 1; last-- )
> > {
> > for ( i = 0; i < last - 1; i++ )
> > {
> > if ( e820_map[i].addr > e820_map[i + 1].addr )
> > {
> > e820_swap_entries(i, i + 1);
> > }
> > }
> > }
>
> Hmm, depends.
>
> Assuming a rather well sorted map my version is O(n), while yours
> is still O(n^2).
Right, I was a bit lazy :)
This should be fine:
/* Sort entries by start address. */
for ( i = 1; i < e820_entries; i++ )
for ( j = i; j > 0 && e820_map[j-1].addr > e820_map[j].addr ) ; j-- )
e820_swap_entries(j - 1, j);
> I'm fine both ways, whatever you prefer.
I really prefer for loops which don't unexpectedly modify their loop
index, that's much less scary :)
Samuel
next prev parent reply other threads:[~2021-12-13 21:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-06 7:23 [PATCH 00/10] mini-os: add missing PVH features Juergen Gross
2021-12-06 7:23 ` [PATCH 01/10] mini-os: split e820 map handling into new source file Juergen Gross
2021-12-11 23:56 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 02/10] mini-os: sort and sanitize e820 memory map Juergen Gross
2021-12-12 0:05 ` Samuel Thibault
2021-12-13 14:56 ` Juergen Gross
2021-12-13 21:19 ` Samuel Thibault [this message]
2021-12-14 6:33 ` Juergen Gross
2021-12-06 7:23 ` [PATCH 03/10] mini-os: don't assume contiguous RAM when initializing in PVH mode Juergen Gross
2021-12-12 0:15 ` Samuel Thibault
2021-12-13 14:58 ` Juergen Gross
2021-12-13 21:22 ` Samuel Thibault
2021-12-14 6:35 ` Juergen Gross
2021-12-14 7:40 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 04/10] mini-os: respect memory map when ballooning up Juergen Gross
2021-12-12 0:26 ` Samuel Thibault
2021-12-13 15:05 ` Juergen Gross
2021-12-06 7:23 ` [PATCH 05/10] mini-os: don't repeat definition available via header file Juergen Gross
2021-12-12 0:27 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 06/10] mini-os: add memory map service functions Juergen Gross
2021-12-12 0:37 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 07/10] mini-os: move x86 specific gnttab coding into arch/x86/gnttab.c Juergen Gross
2021-12-12 0:41 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 08/10] mini-os: add proper pvh grant table handling Juergen Gross
2021-12-12 0:43 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 09/10] mini-os: prepare grantmap entry interface for use by PVH mode Juergen Gross
2021-12-12 0:50 ` Samuel Thibault
2021-12-06 7:23 ` [PATCH 10/10] mini-os: modify grant mappings to work in " Juergen Gross
2021-12-12 0:51 ` Samuel Thibault
2021-12-06 12:46 ` [PATCH] mini-os: support event channel 0 for console Juergen Gross
2021-12-06 13:24 ` Jan Beulich
2021-12-06 13:30 ` Juergen Gross
2021-12-06 14:17 ` Juergen Gross
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=20211213211907.lbjjnvayklf7qucb@begin \
--to=samuel.thibault@ens-lyon.org \
--cc=jgross@suse.com \
--cc=minios-devel@lists.xenproject.org \
--cc=wl@xen.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.