lkml.org 
[lkml]   [2020]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ARM: static kernel in vmalloc space
    Hi,

    On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
    > On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:

    > > 1. SoC w/ LPAE
    > > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
    > > kmap, fixmap & vectors

    > Right, these kind of go together because pre-LPAE cannot do the
    > same TTBR1 split, and they more frequently have conflicting
    > static mappings.
    >
    > It's clearly possible to do something very similar for older chips
    > (v6 or v7 without LPAE, possibly even v5), it just gets harder
    > while providing less benefit.

    Yes, lets have it only for LPAE

    > > 3. TTBR0 (low 3768MB) for user space & lowmem (kernel lowmem to have

    > hardcoded 3840/256 split is likely the best compromise of all the

    hmm,i swallowed 72MB ;)

    > > 4. for user space to/from copy
    > > a. pin user pages
    > > b. kmap user page (can't corresponding lowmem be used instead ?)

    > - In the long run, there is no need for kmap()/kmap_atomic() after
    > highmem gets removed from the kernel, but for the next few years
    > we should still assume that highmem can be used, in order to support
    > systems like the 8GB highbank, armadaxp, keystone2 or virtual
    > machines. For lowmem pages (i.e. all pages when highmem is
    > disabled), kmap_atomic() falls back to page_address() anyway,
    > so there is no much overhead.

    Here i have some confusion - iiuc, VMSPLIT_4G_4G is meant to help
    platforms having RAM > 768M and <= 4GB disable high memory and still
    be able to access full RAM, so high memory shouldn't come into picture,
    right ?. And for the above platforms it can continue current VMPSLIT
    option (the default 3G/1G), no ?, as VMSPLIT_4G_4G can't help complete
    8G to be accessible from lowmem.

    So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of
    caveat in Kconfig help that this is meant for platforms w/ <=4GB), then
    we can do copy_{from,to}_user the same way currently do, and no need to
    do the user page pinning & kmap, right ?

    Only problem i see is Kernel compiled w/ VMSPLIT_4G_4G not suitable
    for >4GB machines, but anyway iiuc, it is was not meant for those
    machines. And it is not going to affect our current multiplatform
    setup as LPAE is not defined in multi_v7.

    Regards
    afzal

    \
     
     \ /
      Last update: 2020-05-14 15:36    [W:2.631 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site