On 14 November 2015 at 14:39, Michael Zimmermann
<sigmaepsilo...@gmail.com> wrote:
> I have an issue with this commit too on my ARMv7 device.
> It causes the whole system to get extremely slow.
>
Since you are top posting a reply into a thread that references two
separate changes (the one that started the thread and the one
mentioned in the message you are replying to), could you please
indicate which exact commit is causing your performance problems?
Thanks,
Ard.
> This is my memmap in case it matters:
> Type Start End # Pages Attributes
> Available 0000000080200000-0000000088DFFFFF 0000000000008C00
> 000000000000000F
> Available 0000000089000000-00000000890FFFFF 0000000000000100
> 000000000000000F
> BS_Data 0000000089100000-00000000898FFFFF 0000000000000800
> 000000000000000F
> Available 0000000089900000-0000000089FFFFFF 0000000000000700
> 000000000000000F
> BS_Data 000000008A000000-000000008A3FFFFF 0000000000000400
> 000000000000000F
> Available 000000008A400000-000000008ABFFFFF 0000000000000800
> 000000000000000F
> Available 000000008AE00000-000000008B3EFFFF 00000000000005F0
> 000000000000000F
> BS_Data 000000008B3F0000-000000008BBFFFFF 0000000000000810
> 000000000000000F
> Available 000000008BC00000-000000008D9FFFFF 0000000000001E00
> 000000000000000F
> Available 000000008EC00000-000000008EFFFFFF 0000000000000400
> 000000000000000F
> Available 000000008F700000-000000008FDFFFFF 0000000000000700
> 000000000000000F
> Available 000000008FF00000-00000000BACF2FFF 000000000002ADF3
> 000000000000000F
> LoaderCode 00000000BACF3000-00000000BADAFFFF 00000000000000BD
> 000000000000000F
> LoaderData 00000000BADB0000-00000000BADB5FFF 0000000000000006
> 000000000000000F
> LoaderCode 00000000BADB6000-00000000BAEEBFFF 0000000000000136
> 000000000000000F
> BS_Code 00000000BAEEC000-00000000BAFA8FFF 00000000000000BD
> 000000000000000F
> RT_Data 00000000BAFA9000-00000000BAFAEFFF 0000000000000006
> 800000000000400F
> RT_Code 00000000BAFAF000-00000000BAFB1FFF 0000000000000003
> 800000000002000F
> RT_Data 00000000BAFB2000-00000000BAFC2FFF 0000000000000011
> 800000000000400F
> RT_Data 00000000BAFC3000-00000000BAFC3FFF 0000000000000001
> 800000000000400F
> RT_Code 00000000BAFC4000-00000000BAFCDFFF 000000000000000A
> 800000000002000F
> RT_Data 00000000BAFCE000-00000000BAFEFFFF 0000000000000022
> 800000000000400F
> RT_Data 00000000BAFF0000-00000000BAFF0FFF 0000000000000001
> 800000000000400F
> RT_Code 00000000BAFF1000-00000000BAFF2FFF 0000000000000002
> 800000000002000F
> RT_Data 00000000BAFF3000-00000000BAFF4FFF 0000000000000002
> 800000000000400F
> Available 00000000BAFF5000-00000000BE483FFF 000000000000348F
> 000000000000000F
> BS_Data 00000000BE484000-00000000BE51AFFF 0000000000000097
> 000000000000000F
> Available 00000000BE51B000-00000000BE53FFFF 0000000000000025
> 000000000000000F
> BS_Data 00000000BE540000-00000000BFE28FFF 00000000000018E9
> 000000000000000F
> Available 00000000BFE29000-00000000BFEBAFFF 0000000000000092
> 000000000000000F
> BS_Code 00000000BFEBB000-00000000BFFB8FFF 00000000000000FE
> 000000000000000F
> RT_Data 00000000BFFB9000-00000000BFFB9FFF 0000000000000001
> 800000000000400F
> RT_Code 00000000BFFBA000-00000000BFFBCFFF 0000000000000003
> 800000000002000F
> RT_Data 00000000BFFBD000-00000000BFFBFFFF 0000000000000003
> 800000000000400F
> RT_Code 00000000BFFC0000-00000000BFFC1FFF 0000000000000002
> 800000000002000F
> RT_Data 00000000BFFC2000-00000000BFFC4FFF 0000000000000003
> 800000000000400F
> RT_Code 00000000BFFC5000-00000000BFFC5FFF 0000000000000001
> 800000000002000F
> RT_Data 00000000BFFC6000-00000000BFFC8FFF 0000000000000003
> 800000000000400F
> RT_Code 00000000BFFC9000-00000000BFFCAFFF 0000000000000002
> 800000000002000F
> RT_Data 00000000BFFCB000-00000000BFFFEFFF 0000000000000034
> 800000000000400F
> BS_Data 00000000BFFFF000-00000000BFFFFFFF 0000000000000001
> 000000000000000F
> Available 00000000C0000000-00000000FFFFFFFF 0000000000040000
> 000000000000000F
>
> On Thu, Nov 12, 2015 at 3:03 PM, Mark Rutland <mark.rutl...@arm.com> wrote:
>>
>> On Thu, Nov 12, 2015 at 11:35:28AM +0000, Leif Lindholm wrote:
>> > Hi Ard,
>> >
>> > On Mon, Nov 09, 2015 at 02:18:58PM +0100, Ard Biesheuvel wrote:
>> > > Mark all cached memory mappings as shareable (or inner shareable on
>> > > AArch64) so that our view of memory is kept coherent by the hardware.
>> > >
>> > > This is primarily relevant under virtualization (where a guest may
>> > > migrate
>> > > to another core) but in general, since UEFI on ARM is mostly used in a
>> > > context where the secure firmware and possibly a secure OS are already
>> > > up
>> > > and running, it is best to refrain from using any non-shareable
>> > > mappings.
>> >
>> > Thanks, this is both an important correctness fix and nice code
>> > cleanup.
>> >
>> > I ran into an issue while testing this, which is why I haven't
>> > responded to this, but I've bisected it down to r18503/3a05b13, and am
>> > looking into what causes an issue with Linux booting.
>>
>> FWIW, I had issues with that which Ard worked around for virtual
>> machines in r18533/2f71ad11d6eaa2af ("ArmVirtPkg: reduce preallocation
>> of boot services data pages").
>>
>> You may be suffering a similar issue.
>>
>> Thanks,
>> Mark.
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
