All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: David Daney <ddaney.cavm@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-xtensa@linux-xtensa.org, Chris Zankel <chris@zankel.net>,
	Marc Gauthier <marc@cadence.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>,
	Steven Hill <Steven.Hill@imgtec.com>
Subject: Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware
Date: Tue, 26 Aug 2014 21:04:30 -0400	[thread overview]
Message-ID: <53FD2E9E.6050809@gentoo.org> (raw)
In-Reply-To: <53FCC7CB.8010701@gmail.com>

On 08/26/2014 13:45, David Daney wrote:
> On 08/25/2014 07:41 PM, Joshua Kinard wrote:
>> On 08/25/2014 20:36, David Daney wrote:
>>> On 08/25/2014 04:55 PM, Joshua Kinard wrote:
>>>> On 08/25/2014 13:16, Ralf Baechle wrote:
>>>>> On Sat, Aug 02, 2014 at 05:11:37AM +0400, Max Filippov wrote:
>>>>>
>>>>>> this series adds mapping color control to the generic kmap code, allowing
>>>>>> architectures with aliasing VIPT cache to use high memory. There's also
>>>>>> use example of this new interface by xtensa.
>>>>>
>>>>> I haven't actually ported this to MIPS but it certainly appears to be
>>>>> the right framework to get highmem aliases handled on MIPS, too.
>>>>>
>>>>> Though I still consider increasing PAGE_SIZE to 16k the preferable
>>>>> solution because it will entirly do away with cache aliases.
>>>>
>>>> Won't setting PAGE_SIZE to 16k break some existing userlands (o32)?  I
>>>> use a
>>>> 4k PAGE_SIZE because the last few times I've tried 16k or 64k, init won't
>>>> load (SIGSEGVs or such, which panicks the kernel).
>>>>
>>>
>>> It isn't supposed to break things.  Using "stock" toolchains should result
>>> in executables that will run with any page size.
>>>
>>> In the past, some geniuses came up with some linker (ld) patches that, in
>>> order to save a few KB of RAM, produced executables that ran only on 4K
>>> pages.
>>>
>>> There were some equally astute Debian emacs package maintainers that were
>>> carrying emacs patches into Debian that would not work on non-4K page size
>>> systems.
>>>
>>> That said, I think such thinking should be punished.  The punishment should
>>> be to not have their software run when we select non-4K page sizes.  The
>>> vast majority of prepackaged software runs just fine with a larger page
>>> size.
>>
>> Well, it does appear to mostly work now w/ 16k PAGE_SIZE.  The Octane booted
>> into userland with just a couple of "illegal instruction" errors from 'rm'
>> and 'mdadm'.  I wonder if that's tied to a hardcoded PAGE_SIZE somewhere.
>> Have to dig around and find something that reproduces the problem on demand.
>>
> 
> What does the output of "readelf -lW" look like for the failing programs? 
> If the "Offset" and "VirtAddr" constraints for the LOAD Program Headers are
> not possible to achieve with the selected PAGE_SIZE, you will see problems. 
> A "correct" toolchain will generate binaries that work with any PAGE_SIZE up
> to 64K.

Well, I recently rebuilt shash, so that might've changed things.  But,
running readelf -lW on shash core dumped readelf itself on the first
invocation (with a SIGBUS instead of SIGILL).  So I instead ran readelf -lW
on itself, which hasn't been recently rebuilt:

# readelf -lW /usr/bin/shash
Bus error (core dumped)
# readelf -lW /usr/bin/readelf

Elf file type is EXEC (Executable file)
Entry point 0x402590
There are 11 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00400034 0x00400034 0x00160 0x00160 R E 0x4
  INTERP         0x000194 0x00400194 0x00400194 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /lib/ld.so.1]
  REGINFO        0x0001c4 0x004001c4 0x004001c4 0x00018 0x00018 R   0x4
  LOAD           0x000000 0x00400000 0x00400000 0x72338 0x72338 R E 0x10000
  LOAD           0x0728c8 0x004828c8 0x004828c8 0x01834 0x03d88 RW  0x10000
  DYNAMIC        0x0001dc 0x004001dc 0x004001dc 0x000e0 0x000e0 RWE 0x4
  NOTE           0x0001a4 0x004001a4 0x004001a4 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x0722c0 0x004722c0 0x004722c0 0x00024 0x00024 R   0x4
  GNU_RELRO      0x0728c8 0x004828c8 0x004828c8 0x00738 0x00738 R   0x1
  PAX_FLAGS      0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4
  NULL           0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .reginfo
   03     .interp .note.ABI-tag .reginfo .dynamic .hash .dynsym .dynstr
.gnu.version .gnu.version_r .init .text .MIPS.stubs .fini .rodata
.eh_frame_hdr .eh_frame
   04     .ctors .dtors .jcr .data.rel.ro .data .rld_map .got .sdata .sbss .bss
   05     .dynamic
   06     .note.ABI-tag
   07     .eh_frame_hdr
   08     .ctors .dtors .jcr .data.rel.ro
   09
   10

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Joshua Kinard <kumba@gentoo.org>
To: David Daney <ddaney.cavm@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-xtensa@linux-xtensa.org, Chris Zankel <chris@zankel.net>,
	Marc Gauthier <marc@cadence.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>,
	Steven Hill <Steven.Hill@imgtec.com>
Subject: Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware
Date: Tue, 26 Aug 2014 21:04:30 -0400	[thread overview]
Message-ID: <53FD2E9E.6050809@gentoo.org> (raw)
Message-ID: <20140827010430.P4QVjOVKOse9wvvAVe3NPPcqDdDTvb6M9cqnTxgX_0Q@z> (raw)
In-Reply-To: <53FCC7CB.8010701@gmail.com>

On 08/26/2014 13:45, David Daney wrote:
> On 08/25/2014 07:41 PM, Joshua Kinard wrote:
>> On 08/25/2014 20:36, David Daney wrote:
>>> On 08/25/2014 04:55 PM, Joshua Kinard wrote:
>>>> On 08/25/2014 13:16, Ralf Baechle wrote:
>>>>> On Sat, Aug 02, 2014 at 05:11:37AM +0400, Max Filippov wrote:
>>>>>
>>>>>> this series adds mapping color control to the generic kmap code, allowing
>>>>>> architectures with aliasing VIPT cache to use high memory. There's also
>>>>>> use example of this new interface by xtensa.
>>>>>
>>>>> I haven't actually ported this to MIPS but it certainly appears to be
>>>>> the right framework to get highmem aliases handled on MIPS, too.
>>>>>
>>>>> Though I still consider increasing PAGE_SIZE to 16k the preferable
>>>>> solution because it will entirly do away with cache aliases.
>>>>
>>>> Won't setting PAGE_SIZE to 16k break some existing userlands (o32)?  I
>>>> use a
>>>> 4k PAGE_SIZE because the last few times I've tried 16k or 64k, init won't
>>>> load (SIGSEGVs or such, which panicks the kernel).
>>>>
>>>
>>> It isn't supposed to break things.  Using "stock" toolchains should result
>>> in executables that will run with any page size.
>>>
>>> In the past, some geniuses came up with some linker (ld) patches that, in
>>> order to save a few KB of RAM, produced executables that ran only on 4K
>>> pages.
>>>
>>> There were some equally astute Debian emacs package maintainers that were
>>> carrying emacs patches into Debian that would not work on non-4K page size
>>> systems.
>>>
>>> That said, I think such thinking should be punished.  The punishment should
>>> be to not have their software run when we select non-4K page sizes.  The
>>> vast majority of prepackaged software runs just fine with a larger page
>>> size.
>>
>> Well, it does appear to mostly work now w/ 16k PAGE_SIZE.  The Octane booted
>> into userland with just a couple of "illegal instruction" errors from 'rm'
>> and 'mdadm'.  I wonder if that's tied to a hardcoded PAGE_SIZE somewhere.
>> Have to dig around and find something that reproduces the problem on demand.
>>
> 
> What does the output of "readelf -lW" look like for the failing programs? 
> If the "Offset" and "VirtAddr" constraints for the LOAD Program Headers are
> not possible to achieve with the selected PAGE_SIZE, you will see problems. 
> A "correct" toolchain will generate binaries that work with any PAGE_SIZE up
> to 64K.

Well, I recently rebuilt shash, so that might've changed things.  But,
running readelf -lW on shash core dumped readelf itself on the first
invocation (with a SIGBUS instead of SIGILL).  So I instead ran readelf -lW
on itself, which hasn't been recently rebuilt:

# readelf -lW /usr/bin/shash
Bus error (core dumped)
# readelf -lW /usr/bin/readelf

Elf file type is EXEC (Executable file)
Entry point 0x402590
There are 11 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00400034 0x00400034 0x00160 0x00160 R E 0x4
  INTERP         0x000194 0x00400194 0x00400194 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /lib/ld.so.1]
  REGINFO        0x0001c4 0x004001c4 0x004001c4 0x00018 0x00018 R   0x4
  LOAD           0x000000 0x00400000 0x00400000 0x72338 0x72338 R E 0x10000
  LOAD           0x0728c8 0x004828c8 0x004828c8 0x01834 0x03d88 RW  0x10000
  DYNAMIC        0x0001dc 0x004001dc 0x004001dc 0x000e0 0x000e0 RWE 0x4
  NOTE           0x0001a4 0x004001a4 0x004001a4 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x0722c0 0x004722c0 0x004722c0 0x00024 0x00024 R   0x4
  GNU_RELRO      0x0728c8 0x004828c8 0x004828c8 0x00738 0x00738 R   0x1
  PAX_FLAGS      0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4
  NULL           0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .reginfo
   03     .interp .note.ABI-tag .reginfo .dynamic .hash .dynsym .dynstr
.gnu.version .gnu.version_r .init .text .MIPS.stubs .fini .rodata
.eh_frame_hdr .eh_frame
   04     .ctors .dtors .jcr .data.rel.ro .data .rld_map .got .sdata .sbss .bss
   05     .dynamic
   06     .note.ABI-tag
   07     .eh_frame_hdr
   08     .ctors .dtors .jcr .data.rel.ro
   09
   10

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

  reply	other threads:[~2014-08-27  1:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-02  1:11 [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware Max Filippov
2014-08-02  1:11 ` Max Filippov
2014-08-02  1:11 ` [PATCH v4 1/2] " Max Filippov
2014-08-02  1:11   ` Max Filippov
2014-08-02  1:11 ` Max Filippov
2014-08-02  1:11 ` Max Filippov
2014-08-02  1:11 ` [PATCH v4 2/2] xtensa: support aliasing cache in kmap Max Filippov
2014-08-02  1:11 ` Max Filippov
2014-08-02  1:11 ` Max Filippov
2014-08-02  1:11   ` Max Filippov
2014-08-25 17:16 ` [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware Ralf Baechle
2014-08-25 17:16   ` Ralf Baechle
2014-08-25 23:55   ` Joshua Kinard
2014-08-25 23:55     ` Joshua Kinard
2014-08-26  0:36     ` David Daney
2014-08-26  0:36       ` David Daney
2014-08-26  2:41       ` Joshua Kinard
2014-08-26  2:41         ` Joshua Kinard
2014-08-26 17:45         ` David Daney
2014-08-26 17:45           ` David Daney
2014-08-27  1:04           ` Joshua Kinard [this message]
2014-08-27  1:04             ` Joshua Kinard
2014-08-26 18:37   ` Leonid Yegoshin
2014-08-26 18:37     ` Leonid Yegoshin

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=53FD2E9E.6050809@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=Leonid.Yegoshin@imgtec.com \
    --cc=Steven.Hill@imgtec.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@zankel.net \
    --cc=ddaney.cavm@gmail.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=marc@cadence.com \
    --cc=ralf@linux-mips.org \
    --cc=rientjes@google.com \
    /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.