1. 16 2月, 2018 7 次提交
  2. 08 2月, 2018 1 次提交
  3. 07 2月, 2018 5 次提交
  4. 06 2月, 2018 1 次提交
    • D
      afs: Support the AFS dynamic root · 4d673da1
      David Howells 提交于
      Support the AFS dynamic root which is a pseudo-volume that doesn't connect
      to any server resource, but rather is just a root directory that
      dynamically creates mountpoint directories where the name of such a
      directory is the name of the cell.
      
      Such a mount can be created thus:
      
      	mount -t afs none /afs -o dyn
      
      Dynamic root superblocks aren't shared except by bind mounts and
      propagation.  Cell root volumes can then be mounted by referring to them by
      name, e.g.:
      
      	ls /afs/grand.central.org/
      	ls /afs/.grand.central.org/
      
      The kernel will upcall to consult the DNS if the address wasn't supplied
      directly.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4d673da1
  5. 05 2月, 2018 2 次提交
  6. 04 2月, 2018 1 次提交
  7. 03 2月, 2018 3 次提交
  8. 02 2月, 2018 7 次提交
  9. 01 2月, 2018 2 次提交
    • M
      mm, hugetlb: remove hugepages_treat_as_movable sysctl · d6cb41cc
      Michal Hocko 提交于
      hugepages_treat_as_movable has been introduced by 396faf03 ("Allow
      huge page allocations to use GFP_HIGH_MOVABLE") to allow hugetlb
      allocations from ZONE_MOVABLE even when hugetlb pages were not
      migrateable.  The purpose of the movable zone was different at the time.
      It aimed at reducing memory fragmentation and hugetlb pages being long
      lived and large werre not contributing to the fragmentation so it was
      acceptable to use the zone back then.
      
      Things have changed though and the primary purpose of the zone became
      migratability guarantee.  If we allow non migrateable hugetlb pages to
      be in ZONE_MOVABLE memory hotplug might fail to offline the memory.
      
      Remove the knob and only rely on hugepage_migration_supported to allow
      movable zones.
      
      Mel said:
      
      : Primarily it was aimed at allowing the hugetlb pool to safely shrink with
      : the ability to grow it again.  The use case was for batched jobs, some of
      : which needed huge pages and others that did not but didn't want the memory
      : useless pinned in the huge pages pool.
      :
      : I suspect that more users rely on THP than hugetlbfs for flexible use of
      : huge pages with fallback options so I think that removing the option
      : should be ok.
      
      Link: http://lkml.kernel.org/r/20171003072619.8654-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Reported-by: NAlexandru Moise <00moses.alexander00@gmail.com>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: Alexandru Moise <00moses.alexander00@gmail.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d6cb41cc
    • R
      mm: show total hugetlb memory consumption in /proc/meminfo · fcb2b0c5
      Roman Gushchin 提交于
      Currently we display some hugepage statistics (total, free, etc) in
      /proc/meminfo, but only for default hugepage size (e.g.  2Mb).
      
      If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
      /proc/meminfo output can be confusing, as non-default sized hugepages
      are not reflected at all, and there are no signs that they are existing
      and consuming system memory.
      
      To solve this problem, let's display the total amount of memory,
      consumed by hugetlb pages of all sized (both free and used).  Let's call
      it "Hugetlb", and display size in kB to match generic /proc/meminfo
      style.
      
      For example, (1024 2Mb pages and 2 1Gb pages are pre-allocated):
        $ cat /proc/meminfo
        MemTotal:        8168984 kB
        MemFree:         3789276 kB
        <...>
        CmaFree:               0 kB
        HugePages_Total:    1024
        HugePages_Free:     1024
        HugePages_Rsvd:        0
        HugePages_Surp:        0
        Hugepagesize:       2048 kB
        Hugetlb:         4194304 kB
        DirectMap4k:       32632 kB
        DirectMap2M:     4161536 kB
        DirectMap1G:     6291456 kB
      
      Also, this patch updates corresponding docs to reflect Hugetlb entry
      meaning and difference between Hugetlb and HugePages_Total * Hugepagesize.
      
      Link: http://lkml.kernel.org/r/20171115231409.12131-1-guro@fb.comSigned-off-by: NRoman Gushchin <guro@fb.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fcb2b0c5
  10. 31 1月, 2018 6 次提交
  11. 28 1月, 2018 2 次提交
    • M
      powerpc/cell: Remove axonram driver · 1d65b1c8
      Michael Ellerman 提交于
      The QS21/22 IBM Cell blades had a southbridge chip called Axon. This
      could have DDR DIMMs attached to it, though they were not directly
      usable as RAM, instead they could be used as some sort of buffer, if
      applications were written specifically to use the block device
      provided by the driver.
      
      Although the driver supposedly had direct access support, it was
      apparently never tested (see commit 91117a20 ("axonram: Fix bug in
      direct_access")).
      
      These machines have not been available for over 5 years, and were
      never widely in use. It seems highly unlikely anyone is using this
      driver.
      
      In general we're happy to leave old drivers in the tree, but because
      DAX is involved this driver is caught up in the ongoing work in that
      area, but none of the DAX folks are able to test it.
      
      So remove the driver, if any one *is* using it, we'll be happy to put
      it back.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      1d65b1c8
    • M
      kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help · cedd55d4
      Marc Herbert 提交于
      As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
      silentoldconfig has become a misnomer. It has become an internal interface
      so remove it from "make help" and Documentation/ to stop confusing people
      using it as seen for instance at
      https://chromium-review.googlesource.com/835632 Don't remove it from
      kconfig/Makefile yet not to break any (other) tool using it.
      
      On the other hand, correct and expand its description in the help of
      the (internal) scripts/kconfig/conf.c
      Signed-off-by: NMarc Herbert <marc.herbert@intel.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      cedd55d4
  12. 27 1月, 2018 3 次提交