On Tue, 4 Sep 2018, Paul Menzel wrote:
> On 08/22/18 15:41, Thomas Gleixner wrote:
> > On Wed, 22 Aug 2018, Paul Menzel wrote:
> >> Am 21.08.2018 um 11:37 schrieb Paul Menzel:
> >>> [Removed non-working Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>]
> >>
> >> So “free’ing” pfn = 225278 to e_pfn = 818492 in the for loop takes 160 ms.
> >
> > That's 593214 pages and each one takes about 270ns. I don't see much
> > optimization potential with that.
> >
> > 32bit and highmem sucks ...
We all know that.
> Interestingly on my ASRock E350M1 with 4 GB, `pfn_valid()` is always true.
>
> Additionally, after removing the for loop, the system still boots and seems
> to work fine.
>
> Here is the hunk I removed (with my debug statements).
>
> - for ( ; pfn < e_pfn; pfn++)
> - if (pfn_valid(pfn)) {
> - free_highmem_page(pfn_to_page(pfn));
> - //printk(KERN_INFO "%s: in for loop pfn_valid(pfn) after fre
> e_highmem_page, pfn = %lu\n", __func__, pfn);
> - } else {
> - printk(KERN_INFO "%s: pfn = %lu is invalid\n", __func__);
> - }
>
> Is the code there for certain memory sizes?
No, it's there to give the highmem pages back for allocation. You're losing
usable memory that way. /proc/meminfo should tell you the difference.
Thanks,
tglx
