1. 19 3月, 2019 2 次提交
  2. 18 3月, 2019 1 次提交
    • R
      networking: fix snmp_counter.rst Doc. Warnings · 65e9a6d2
      Randy Dunlap 提交于
      Fix documentation markup warnings in snmp_counter.rst:
      
      Documentation/networking/snmp_counter.rst:416: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:684: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:693: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:707: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:712: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:722: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:733: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:736: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:739: WARNING: Bullet list ends without a blank line; unexpected unindent.
      
      Fixes: 80cc4950 ("net: Add part of TCP counts explanations in snmp_counters.rst")
      Fixes: 8e2ea53a ("add snmp counters document")
      Fixes: a6c7c7aa ("net: add document for several snmp counters")
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: yupeng <yupeng0921@gmail.com>
      65e9a6d2
  3. 13 3月, 2019 2 次提交
  4. 12 3月, 2019 1 次提交
  5. 09 3月, 2019 2 次提交
  6. 08 3月, 2019 4 次提交
    • D
      lib/lzo: separate lzo-rle from lzo · 45ec975e
      Dave Rodgman 提交于
      To prevent any issues with persistent data, separate lzo-rle from lzo so
      that it is treated as a separate algorithm, and lzo is still available.
      
      Link: http://lkml.kernel.org/r/20190205155944.16007-3-dave.rodgman@arm.comSigned-off-by: NDave Rodgman <dave.rodgman@arm.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com>
      Cc: Matt Sealey <matt.sealey@arm.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <nitingupta910@gmail.com>
      Cc: Richard Purdie <rpurdie@openedhand.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Sonny Rao <sonnyrao@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      45ec975e
    • D
      lib/lzo: implement run-length encoding · 5ee4014a
      Dave Rodgman 提交于
      Patch series "lib/lzo: run-length encoding support", v5.
      
      Following on from the previous lzo-rle patchset:
      
        https://lkml.org/lkml/2018/11/30/972
      
      This patchset contains only the RLE patches, and should be applied on
      top of the non-RLE patches ( https://lkml.org/lkml/2019/2/5/366 ).
      
      Previously, some questions were raised around the RLE patches.  I've
      done some additional benchmarking to answer these questions.  In short:
      
       - RLE offers significant additional performance (data-dependent)
      
       - I didn't measure any regressions that were clearly outside the noise
      
      One concern with this patchset was around performance - specifically,
      measuring RLE impact separately from Matt Sealey's patches (CTZ & fast
      copy).  I have done some additional benchmarking which I hope clarifies
      the benefits of each part of the patchset.
      
      Firstly, I've captured some memory via /dev/fmem from a Chromebook with
      many tabs open which is starting to swap, and then split this into 4178
      4k pages.  I've excluded the all-zero pages (as zram does), and also the
      no-zero pages (which won't tell us anything about RLE performance).
      This should give a realistic test dataset for zram.  What I found was
      that the data is VERY bimodal: 44% of pages in this dataset contain 5%
      or fewer zeros, and 44% contain over 90% zeros (30% if you include the
      no-zero pages).  This supports the idea of special-casing zeros in zram.
      
      Next, I've benchmarked four variants of lzo on these pages (on 64-bit
      Arm at max frequency): baseline LZO; baseline + Matt Sealey's patches
      (aka MS); baseline + RLE only; baseline + MS + RLE.  Numbers are for
      weighted roundtrip throughput (the weighting reflects that zram does
      more compression than decompression).
      
        https://drive.google.com/file/d/1VLtLjRVxgUNuWFOxaGPwJYhl_hMQXpHe/view?usp=sharing
      
      Matt's patches help in all cases for Arm (and no effect on Intel), as
      expected.
      
      RLE also behaves as expected: with few zeros present, it makes no
      difference; above ~75%, it gives a good improvement (50 - 300 MB/s on
      top of the benefit from Matt's patches).
      
      Best performance is seen with both MS and RLE patches.
      
      Finally, I have benchmarked the same dataset on an x86-64 device.  Here,
      the MS patches make no difference (as expected); RLE helps, similarly as
      on Arm.  There were no definite regressions; allowing for observational
      error, 0.1% (3/4178) of cases had a regression > 1 standard deviation,
      of which the largest was 4.6% (1.2 standard deviations).  I think this
      is probably within the noise.
      
        https://drive.google.com/file/d/1xCUVwmiGD0heEMx5gcVEmLBI4eLaageV/view?usp=sharing
      
      One point to note is that the graphs show RLE appears to help very
      slightly with no zeros present! This is because the extra code causes
      the clang optimiser to change code layout in a way that happens to have
      a significant benefit.  Taking baseline LZO and adding a do-nothing line
      like "__builtin_prefetch(out_len);" immediately before the "goto next"
      has the same effect.  So this is a real, but basically spurious effect -
      it's small enough not to upset the overall findings.
      
      This patch (of 3):
      
      When using zram, we frequently encounter long runs of zero bytes.  This
      adds a special case which identifies runs of zeros and encodes them
      using run-length encoding.
      
      This is faster for both compression and decompresion.  For high-entropy
      data which doesn't hit this case, impact is minimal.
      
      Compression ratio is within a few percent in all cases.
      
      This modifies the bitstream in a way which is backwards compatible
      (i.e., we can decompress old bitstreams, but old versions of lzo cannot
      decompress new bitstreams).
      
      Link: http://lkml.kernel.org/r/20190205155944.16007-2-dave.rodgman@arm.comSigned-off-by: NDave Rodgman <dave.rodgman@arm.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com>
      Cc: Matt Sealey <matt.sealey@arm.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <nitingupta910@gmail.com>
      Cc: Richard Purdie <rpurdie@openedhand.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Sonny Rao <sonnyrao@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ee4014a
    • M
      kernel/configs: use .incbin directive to embed config_data.gz · 13610aa9
      Masahiro Yamada 提交于
      This slightly optimizes the kernel/configs.c build.
      
      bin2c is not very efficient because it converts a data file into a huge
      array to embed it into a *.c file.
      
      Instead, we can use the .incbin directive.
      
      Also, this simplifies the code; Makefile is cleaner, and the way to get
      the offset/size of the config_data.gz is more straightforward.
      
      I used the "asm" statement in *.c instead of splitting it into *.S
      because MODULE_* tags are not supported in *.S files.
      
      I also cleaned up kernel/.gitignore; "config_data.gz" is unneeded
      because the top-level .gitignore takes care of the "*.gz" pattern.
      
      [yamada.masahiro@socionext.com: v2]
        Link: http://lkml.kernel.org/r/1550108893-21226-1-git-send-email-yamada.masahiro@socionext.com
      Link: http://lkml.kernel.org/r/1549941160-8084-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Alexander Popov <alex.popov@linux.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Richard Guy Briggs <rgb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13610aa9
    • A
      configs: get rid of obsolete CONFIG_ENABLE_WARN_DEPRECATED · 3337d5cf
      Alexey Brodkin 提交于
      This Kconfig option was removed during v4.19 development in commit
      771c0353 ("deprecate the '__deprecated' attribute warnings entirely
      and for good") so there's no point to keep it in defconfigs any longer.
      
      FWIW defconfigs were patched with:
      --------------------------->8----------------------
      find . -name *_defconfig -exec sed -i '/CONFIG_ENABLE_WARN_DEPRECATED/d' {} \;
      --------------------------->8----------------------
      
      Link: http://lkml.kernel.org/r/20190128152434.41969-1-abrodkin@synopsys.comSigned-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3337d5cf
  7. 07 3月, 2019 5 次提交
  8. 06 3月, 2019 7 次提交
    • A
      mm: remove zone_lru_lock() function, access ->lru_lock directly · f4b7e272
      Andrey Ryabinin 提交于
      We have common pattern to access lru_lock from a page pointer:
      	zone_lru_lock(page_zone(page))
      
      Which is silly, because it unfolds to this:
      	&NODE_DATA(page_to_nid(page))->node_zones[page_zonenum(page)]->zone_pgdat->lru_lock
      while we can simply do
      	&NODE_DATA(page_to_nid(page))->lru_lock
      
      Remove zone_lru_lock() function, since it's only complicate things.  Use
      'page_pgdat(page)->lru_lock' pattern instead.
      
      [aryabinin@virtuozzo.com: a slightly better version of __split_huge_page()]
        Link: http://lkml.kernel.org/r/20190301121651.7741-1-aryabinin@virtuozzo.com
      Link: http://lkml.kernel.org/r/20190228083329.31892-2-aryabinin@virtuozzo.comSigned-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f4b7e272
    • C
      mm: memcontrol: expose THP events on a per-memcg basis · 1ff9e6e1
      Chris Down 提交于
      Currently THP allocation events data is fairly opaque, since you can
      only get it system-wide.  This patch makes it easier to reason about
      transparent hugepage behaviour on a per-memcg basis.
      
      For anonymous THP-backed pages, we already have MEMCG_RSS_HUGE in v1,
      which is used for v1's rss_huge [sic].  This is reused here as it's
      fairly involved to untangle NR_ANON_THPS right now to make it per-memcg,
      since right now some of this is delegated to rmap before we have any
      memcg actually assigned to the page.  It's a good idea to rework that,
      but let's leave untangling THP allocation for a future patch.
      
      [akpm@linux-foundation.org: fix build]
      [chris@chrisdown.name: fix memcontrol build when THP is disabled]
        Link: http://lkml.kernel.org/r/20190131160802.GA5777@chrisdown.name
      Link: http://lkml.kernel.org/r/20190129205852.GA7310@chrisdown.nameSigned-off-by: NChris Down <chris@chrisdown.name>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ff9e6e1
    • D
      mm: convert PG_balloon to PG_offline · ca215086
      David Hildenbrand 提交于
      PG_balloon was introduced to implement page migration/compaction for
      pages inflated in virtio-balloon.  Nowadays, it is only a marker that a
      page is part of virtio-balloon and therefore logically offline.
      
      We also want to make use of this flag in other balloon drivers - for
      inflated pages or when onlining a section but keeping some pages offline
      (e.g.  used right now by XEN and Hyper-V via set_online_page_callback()).
      
      We are going to expose this flag to dump tools like makedumpfile.  But
      instead of exposing PG_balloon, let's generalize the concept of marking
      pages as logically offline, so it can be reused for other purposes later
      on.
      
      Rename PG_balloon to PG_offline.  This is an indicator that the page is
      logically offline, the content stale and that it should not be touched
      (e.g.  a hypervisor would have to allocate backing storage in order for
      the guest to dump an unused page).  We can then e.g.  exclude such pages
      from dumps.
      
      We replace and reuse KPF_BALLOON (23), as this shouldn't really harm
      (and for now the semantics stay the same).  In following patches, we
      will make use of this bit also in other balloon drivers.  While at it,
      document PGTABLE.
      
      [akpm@linux-foundation.org: fix comment text, per David]
      Link: http://lkml.kernel.org/r/20181119101616.8901-3-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NKonstantin Khlebnikov <koct9i@gmail.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NPankaj gupta <pagupta@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Christian Hansen <chansen3@cisco.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Miles Chen <miles.chen@mediatek.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Julien Freche <jfreche@vmware.com>
      Cc: Kairui Song <kasong@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Lianbo Jiang <lijiang@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Nadav Amit <namit@vmware.com>
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Xavier Deguillard <xdeguillard@vmware.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca215086
    • M
      dm cache: add support for discard passdown to the origin device · de7180ff
      Mike Snitzer 提交于
      DM cache now defaults to passing discards down to the origin device.
      User may disable this using the "no_discard_passdown" feature when
      creating the cache device.
      
      If the cache's underlying origin device doesn't support discards then
      passdown is disabled (with warning).  Similarly, if the underlying
      origin device's max_discard_sectors is less than a cache block discard
      passdown will be disabled (this is required because sizing of the cache
      internal discard bitset depends on it).
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      de7180ff
    • H
      dm: add support to directly boot to a mapped device · 6bbc923d
      Helen Koike 提交于
      Add a "create" module parameter, which allows device-mapper targets to
      be configured at boot time. This enables early use of DM targets in the
      boot process (as the root device or otherwise) without the need of an
      initramfs.
      
      The syntax used in the boot param is based on the concise format from
      the dmsetup tool to follow the rule of least surprise:
      
      	dmsetup table --concise /dev/mapper/lroot
      
      Which is:
      	dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
      
      Where,
      	<name>		::= The device name.
      	<uuid>		::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
      	<minor>		::= The device minor number | ""
      	<flags>		::= "ro" | "rw"
      	<table>		::= <start_sector> <num_sectors> <target_type> <target_args>
      	<target_type>	::= "verity" | "linear" | ...
      
      For example, the following could be added in the boot parameters:
      dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
      
      Only the targets that were tested are allowed and the ones that don't
      change any block device when the device is create as read-only. For
      example, mirror and cache targets are not allowed. The rationale behind
      this is that if the user makes a mistake, choosing the wrong device to
      be the mirror or the cache can corrupt data.
      
      The only targets initially allowed are:
      * crypt
      * delay
      * linear
      * snapshot-origin
      * striped
      * verity
      Co-developed-by: NWill Drewry <wad@chromium.org>
      Co-developed-by: NKees Cook <keescook@chromium.org>
      Co-developed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: NHelen Koike <helen.koike@collabora.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      6bbc923d
    • J
      Documentation: modern versions of ceph are not backed by btrfs · d11ae8e0
      Jeff Layton 提交于
      [ Update the links too. ]
      Signed-off-by: NJeff Layton <jlayton@kernel.org>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      d11ae8e0
    • Y
      ceph: add mount option to limit caps count · fe33032d
      Yan, Zheng 提交于
      If number of caps exceed the limit, ceph_trim_dentires() also trim
      dentries with valid leases. Trimming dentry releases references to
      associated inode, which may evict inode and release caps.
      
      By default, there is no limit for caps count.
      Signed-off-by: N"Yan, Zheng" <zyan@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      fe33032d
  9. 05 3月, 2019 5 次提交
  10. 04 3月, 2019 6 次提交
  11. 03 3月, 2019 2 次提交
  12. 02 3月, 2019 3 次提交