aim in skb_page_frag_refill(), but it is not
> >> masked off in __page_frag_cache_refill().
> >>
> >> This patch unifies the gfp bits used between different
> >> implementions by or'ing __GFP_NOMEMALLOC and masking off
> >> __GFP_DIRECT_RECLAIM for or
On Mon, Jan 8, 2024 at 1:06 AM Yunsheng Lin wrote:
>
> On 2024/1/6 0:06, Alexander H Duyck wrote:
> >>
> >> static void handle_tx_copy(struct vhost_net *net, struct socket *sock)
> >> @@ -1353,8 +1318,7 @@ static int vhost_net_open(struct inode *inode,
> >> struct file *f)
> >>
On Wed, Apr 7, 2021 at 11:07 AM Jakub Kicinski wrote:
>
> On Wed, 7 Apr 2021 09:25:28 -0700 Alexander Duyck wrote:
> > On Wed, Apr 7, 2021 at 8:37 AM Jakub Kicinski wrote:
> > >
> > > On Wed, 7 Apr 2021 08:00:53 +0200 Oleksandr Natalenko wrote:
> > > >
On Wed, Apr 7, 2021 at 8:37 AM Jakub Kicinski wrote:
>
> On Wed, 7 Apr 2021 08:00:53 +0200 Oleksandr Natalenko wrote:
> > Thanks for the effort, but reportedly [1] it made no difference,
> > unfortunately.
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=212573#c8
>
> The only other option
On Fri, Mar 26, 2021 at 2:45 AM Xunlei Pang wrote:
>
> We encountered user memory allocation failure(OOM) on our
> 512MiB tiny instances, it didn't happen after turning off
> the page reporting.
>
> After some debugging, it turns out 32*4MB=128MB(order-10)
> free pages were isolated during
On Fri, Mar 26, 2021 at 2:45 AM Xunlei Pang wrote:
>
> Add new "/sys/kernel/mm/page_reporting/reporting_factor"
> within [0, 100], and stop page reporting when it reaches
> the configured threshold. Default is 100 which means no
> limitation is imposed. Percentile is adopted to reflect
> the fact
On Fri, Mar 26, 2021 at 2:45 AM Xunlei Pang wrote:
>
> It's useful to know how many memory has been actually reported,
> so add new zone::reported_pages to record that.
>
> Add "/sys/kernel/mm/page_reporting/reported_kbytes" for the
> actual memory has been reported.
>
> Add
page_alloc.c | 6 +-
> > mm/page_reporting.c | 268
> > ++--
> > 4 files changed, 260 insertions(+), 20 deletions(-)
> >
>
> Hi guys,
>
> Looks "Alexander Duyck " was not
> available, so Cced mo
On Mon, Mar 22, 2021 at 2:26 AM Antoine Tenart wrote:
>
> Quoting Matthew Wilcox (2021-03-22 10:05:36)
> > On Mon, Mar 22, 2021 at 09:55:50AM +0100, Antoine Tenart wrote:
> > > I only had a quick look at this, but I think the issue should be fixed
> > > with:
> > >
> > > diff --git
+-
> include/linux/if_rmnet.h | 65 +--
> 5 files changed, 69 insertions(+), 89 deletions(-)
>
Other than the minor nit I pointed out in patch 2 the set looks good to me.
Reviewed-by: Alexander Duyck
On Mon, Mar 15, 2021 at 6:36 AM Alex Elder wrote:
>
> In rmnet_map_ipv4_ul_csum_header() and rmnet_map_ipv6_ul_csum_header()
> the offset within a packet at which checksumming should commence is
> calculated. This calculation involves byte swapping and a forced type
> conversion that makes it
On Mon, Mar 15, 2021 at 8:01 AM Alex Elder wrote:
>
> In review, Alexander Duyck suggested that ipa_table_hash_support()
> was trivial enough that it could be implemented as a static inline
> function in the header file. But the patch had already been
> accepted. Implement
; Hi Mel-
>
> This patch replaces patch 5/7 in v4 of your alloc_pages_bulk()
> series. It implements code clean-ups suggested by Alexander Duyck.
> It builds and has seen some light testing.
>
>
> net/sunrpc/svc_xprt.c | 39 +++
>
On Fri, Mar 12, 2021 at 7:43 AM Mel Gorman wrote:
>
> From: Jesper Dangaard Brouer
>
> There are cases where the page_pool need to refill with pages from the
> page allocator. Some workloads cause the page_pool to release pages
> instead of recycling these pages.
>
> For these workload it can
On Fri, Mar 12, 2021 at 7:43 AM Mel Gorman wrote:
>
> From: Chuck Lever
>
> Reduce the rate at which nfsd threads hammer on the page allocator.
> This improves throughput scalability by enabling the threads to run
> more independently of each other.
>
> Signed-off-by: Chuck Lever
>
On Thu, Mar 11, 2021 at 3:49 AM Mel Gorman wrote:
>
> This patch adds a new page allocator interface via alloc_pages_bulk,
> and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> to be allocated and added to a list. They can be freed in bulk using
> free_pages_bulk().
>
> The API
Hi Bala,
There was a similar effort several months ago that was trying to do
this in conjunction with pre-zeroing of pages. I suspect if you wanted
to you could probably pick up some of their patch set and work with
that. It can be found at:
https://www.spinics.net/lists/linux-mm/msg239735.html
0000001
> [5.756635] R10: 7ff640391300 R11: 0246 R12:
> 010929e0
> [5.757029] R13: R14: 01092dd0 R15:
> 0001
>
> On Mon, Mar 8, 2021 at 12:47 PM Alexander Duyck
> wrote:
> >
> > On Mon, Mar 8
On Mon, Mar 8, 2021 at 12:39 AM Tong Zhang wrote:
>
> there are two drivers(zatm and idt77252) using PRIV() (i.e. atm->phy_data)
> to store private data, but the driver happens to populate wrong
> pointers: atm->dev_data. which actually cause null-ptr-dereference in
> following PRIV(dev). This
16 +-
> net/core/skbuff.c | 428 +++--
> 3 files changed, 242 insertions(+), 206 deletions(-)
>
With the last few changes and testing to verify the need to drop the
cache clearing this patch set looks good to me.
Reviewed-by: Alexander Duyck
On Fri, Feb 12, 2021 at 6:40 AM Alex Elder wrote:
>
> Introduce a new function to abstract the knowledge of whether hashed
> routing and filter tables are supported for a given IPA instance.
>
> IPA v4.2 is the only one that doesn't support hashed tables (now
> and for the foreseeable future),
On Thu, Feb 11, 2021 at 10:57 AM Alexander Lobakin wrote:
>
> This function isn't much needed as NAPI skb queue gets bulk-freed
> anyway when there's no more room, and even may reduce the efficiency
> of bulk operations.
> It will be even less needed after reusing skb cache on allocation path,
>
On Thu, Feb 11, 2021 at 11:00 AM Alexander Lobakin wrote:
>
> Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
> an skbuff_head from the NAPI cache instead of inplace allocation
> inside __alloc_skb().
> This implies that the function is called from softirq or BH-off
> context,
On Sun, Feb 7, 2021 at 10:32 PM Samuel Holland wrote:
>
> Use the appropriate function instead of reimplementing it,
> and update the error message to match the code.
>
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Samuel Holland
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6
On 1/12/21 1:16 PM, Alexander Lobakin wrote:
Commit 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") actually
not only added a support for fraglisted UDP GRO, but also tweaked
some logics the way that non-fraglisted UDP GRO started to work for
forwarding too.
Tests showed that currently
> This patch try to solve this issue, when there is no free page
> > > and page repoting is on going, wait until it is done.
> > >
> > > Cc: Alexander Duyck
> >
> > Please don't use this email address for me anymore. Either use
> > alexander.du...@gmai
his issue, when there is no free page
> and page repoting is on going, wait until it is done.
>
> Cc: Alexander Duyck
Please don't use this email address for me anymore. Either use
alexander.du...@gmail.com or alexanderdu...@fb.com. I am getting
bounces when I reply to this thread because of the
On Tue, Jan 5, 2021 at 7:48 PM Liang Li wrote:
>
> Some key parameters for page reporting are now hard coded, different
> users of the framework may have their special requirements, make
> these parameter configrable and let the user decide them.
>
> Cc: Alexander Duyck
>
up for a sigle page
> may not worth.
> This patch add a batch size as another threshold to control the
> waking up of reporting worker.
>
> Cc: Alexander Duyck
> Cc: Mel Gorman
> Cc: Andrea Arcangeli
> Cc: Dan Williams
> Cc: Dave Hansen
> Cc: David Hildenbrand
On Tue, Dec 22, 2020 at 7:39 PM Liang Li wrote:
>
> > > +hugepage_reporting_cycle(struct page_reporting_dev_info *prdev,
> > > +struct hstate *h, unsigned int nid,
> > > +struct scatterlist *sgl, unsigned int *offset)
> > > +{
> > > + struct
duce the memory management overhead and improve system
> performance.
> This patch add the support for reporting hugepages in the free list
> of hugetlb, it canbe used by virtio_balloon driver for memory
> overcommit and pre zero out free pages for speeding up memory population.
>
&g
On Mon, Dec 21, 2020 at 8:25 AM Liang Li wrote:
>
> The first version can be found at: https://lkml.org/lkml/2020/4/12/42
>
> Zero out the page content usually happens when allocating pages with
> the flag of __GFP_ZERO, this is a time consuming operation, it makes
> the population of a large vma
40 ++
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 59 -
> 4 files changed, 53 insertions(+), 51 deletions(-)
>
The changes look good to me.
Reviewed-by: Alexander Duyck
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
On Sat, Dec 12, 2020 at 11:07 AM Yuchung Cheng wrote:
>
> On Sat, Dec 12, 2020 at 11:01 AM Alexander Duyck
> wrote:
> >
> > On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng wrote:
> > >
> > > On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> > &g
On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng wrote:
>
> On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> > message in the case of IPv6
From: Alexander Duyck
There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame
On Fri, Dec 11, 2020 at 11:18 AM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 6:15 PM Alexander Duyck
> wrote:
> >
> > On Fri, Dec 11, 2020 at 8:22 AM Eric Dumazet wrote:
> > >
> > > On Fri, Dec 11, 2020 at 5:03 PM Alexander Duyck
> > >
On Fri, Dec 11, 2020 at 8:22 AM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 5:03 PM Alexander Duyck
> wrote:
>
> > That's fine. I can target this for net-next. I had just selected net
> > since I had considered it a fix, but I suppose it could be considered
> &g
On Thu, Dec 10, 2020 at 10:24 PM Eric Dumazet wrote:
>
> On Fri, Dec 11, 2020 at 2:55 AM Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > In the case of a fastopen SYN there are cases where it may trigger either a
> > ICMP_TOOBIG message
From: Alexander Duyck
In the case of a fastopen SYN there are cases where it may trigger either a
ICMP_TOOBIG message in the case of IPv6 or a fragmentation request in the
case of IPv4. This results in the socket stalling for a second or more as
it does not respond to the message
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
>
> Hi,
>
> On 12/8/20 5:14 PM, Alexander Duyck wrote:
> > On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 12/8/20 6:08 AM, Neftin, Sasha wrote:
> >&g
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
>
> Hi,
>
> On 12/8/20 6:08 AM, Neftin, Sasha wrote:
> > On 12/7/2020 17:41, Limonciello, Mario wrote:
> >>> First of all thank you for working on this.
> >>>
> >>> I must say though that I don't like the approach taken here very
> >>> much.
>
On Sat, Dec 5, 2020 at 3:49 PM Jakub Kicinski wrote:
>
> On Fri, 4 Dec 2020 14:38:03 -0800 Alexander Duyck wrote:
> > > > The patches look good to me. Just need to address the minor issue that
> > > > seems to have been present prior to the introduc
On Fri, Dec 4, 2020 at 2:28 PM Limonciello, Mario
wrote:
>
> > -Original Message-
> > From: Alexander Duyck
> > Sent: Friday, December 4, 2020 15:27
> > To: Limonciello, Mario
> > Cc: Jeff Kirsher; Tony Nguyen; intel-wired-lan; LKML; Linux PM; Netde
st need to address the minor issue that
seems to have been present prior to the introduction of this patch
set.
Reviewed-by: Alexander Duyck
On Fri, Dec 4, 2020 at 12:09 PM Mario Limonciello
wrote:
>
> Introduce a flag to indicate the device should be using the S0ix
> flows and use this flag to run those functions.
>
> Splitting the code to it's own file will make future heuristics
> more self contained.
>
> Tested-by: Yijun Shen
>
g the MCAM entries via debugfs.
> * Patches 8 to 10 adds support for VLAN offload.
> * Patch 10 to 11 adds support for SR-IOV ndo handlers.
> * Patch 12 adds support to read the MCAM entries.
>
> Misc:
> * Removed redundant mailbox NIX_RXVLAN_ALLOC.
>
> Change-log:
> v4:
On Tue, Nov 10, 2020 at 11:22 PM Naveen Mamindlapalli
wrote:
>
> From: Subbaraya Sundeep
>
> Added new mailbox messages to install and delete MCAM rules.
> These mailbox messages will be used for adding/deleting ethtool
> n-tuple filters by NIX PF. The installed MCAM rules are stored
> in a list
ields such as channel and DMAC
> are not overwritten by the KEX configuration of other fields.
>
> Signed-off-by: Subbaraya Sundeep
> Signed-off-by: Sunil Goutham
> Signed-off-by: Naveen Mamindlapalli
A few minor spelling issues, otherwise it looks fine.
Reviewed-by: Alexander Duyck
>
t by the
> mailbox user.
>
> Signed-off-by: Subbaraya Sundeep
> Signed-off-by: Kiran Kumar K
> Signed-off-by: Sunil Goutham
> Signed-off-by: Naveen Mamindlapalli
One minor nit below. Otherwise looks good to me.
Reviewed-by: Alexander Duyck
> ---
> drivers/net/e
uld be useful. However other than that the
code itself appears to make sense.
Reviewed-by: Alexander Duyck
> ---
> .../ethernet/marvell/octeontx2/af/npc_profile.h| 71
> --
> .../net/ethernet/marvell/octeontx2/af/rvu_nix.c| 6 ++
> 2 files changed, 7
On Thu, Oct 1, 2020 at 11:47 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 9:33 PM Alexander Duyck
> wrote:
> > On Thu, Oct 1, 2020 at 9:37 AM Andy Shevchenko
> > wrote:
> > > On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> > > wrote:
>
On Thu, Oct 1, 2020 at 11:06 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 8:44 PM Alexander Duyck
> wrote:
> > On Thu, Oct 1, 2020 at 9:26 AM Andy Shevchenko
> > wrote:
> > > On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> > > wrote:
>
On Thu, Oct 1, 2020 at 9:37 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> wrote:
> > Add support for the Intel Platform Monitoring Technology crashlog
> > interface. This interface provides a few sysfs values to allow for
> > controlling the crashlog telemetry
On Thu, Oct 1, 2020 at 9:26 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> wrote:
> >
> > From: Alexander Duyck
> >
> > Intel Platform Monitoring Technology is meant to provide a common way to
> > access telemetry and sy
On Thu, Oct 1, 2020 at 9:03 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> wrote:
> >
> > From: Alexander Duyck
> >
> > PMT Telemetry is a capability of the Intel Platform Monitoring Technology.
> > The Telemetry capabil
On Mon, Sep 28, 2020 at 6:24 PM Randy Dunlap wrote:
>
> On 9/28/20 5:53 PM, David E. Box wrote:
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 40219bba6801..093c43b63f48 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
>
iewior
> Signed-off-by: Thomas Gleixner
> Cc: Jeff Kirsher
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Cc: net...@vger.kernel.org
The patch looks good to me.
Reviewed-by: Alexander Duyck
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c |1 -
&
On Mon, Sep 21, 2020 at 9:07 AM Alexey Budankov
wrote:
>
>
> On 21.09.2020 16:36, Alexander Duyck wrote:
> > On Sat, Sep 19, 2020 at 1:01 AM Alexey Budankov
> > wrote:
> >>
> >> Hi,
> >>
> >> Thanks for the patches.
> >>
> &g
On Mon, Sep 21, 2020 at 6:16 AM Hans de Goede wrote:
>
> Hi,
>
> On 9/17/20 11:35 PM, Alexander Duyck wrote:
> > On Thu, Sep 17, 2020 at 5:12 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 9/15/20 12:35 AM, Alexander Duyck wrote:
On Sat, Sep 19, 2020 at 1:01 AM Alexey Budankov
wrote:
>
> Hi,
>
> Thanks for the patches.
>
> On 11.09.2020 22:45, David E. Box wrote:
> > From: Alexander Duyck
> >
> > Add support for the Intel Platform Monitoring Technology crashlog
> > interface.
On Thu, Sep 17, 2020 at 5:12 AM Hans de Goede wrote:
>
> Hi,
>
> On 9/15/20 12:35 AM, Alexander Duyck wrote:
> > On Mon, Sep 14, 2020 at 11:07 AM Alexander Duyck
> > wrote:
> >>
> >> On Mon, Sep 14, 2020 at 6:42 AM Hans de Goede wrote:
> >>
> > Signed-off-by: Liu Shixin
>
> Applied to pci/misc for v5.10, thanks!
The code below seems pretty straight forward.
Acked-by: Alexander Duyck
> > ---
> > drivers/pci/pci-pf-stub.c | 14 +-
> > 1 file changed, 1 insertion(+), 13 deletions(-)
> >
>
On Thu, Sep 17, 2020 at 7:26 AM Daniel Jordan
wrote:
>
> On Thu, Sep 17, 2020 at 10:37:45AM +0800, Alex Shi wrote:
> > 在 2020/9/16 上午12:58, Daniel Jordan 写道:
> > > On Tue, Sep 15, 2020 at 01:21:56AM -0700, Hugh Dickins wrote:
> > >> On Sun, 13 Sep 2020, Alex Shi wrote:
> > >>> Uh, I updated the
ype - should
> be good enough for internal purposes.
>
> Cc: Andrew Morton
> Cc: Alexander Duyck
> Cc: Mel Gorman
> Cc: Michal Hocko
> Cc: Dave Hansen
> Cc: Vlastimil Babka
> Cc: Wei Yang
> Cc: Oscar Salvador
> Cc: Mike Rapoport
> Signed-off-by:
on due to the changed page isolation
> behavior (which I doubt), we can always make this configurable by the
> instance triggering undo of isolation (e.g., alloc_contig_range(),
> memory onlining, memory offlining).
>
> Cc: Andrew Morton
> Cc: Alexander Duyck
> Cc: Mel Gorman
> Cc: M
On Mon, Sep 14, 2020 at 11:07 AM Alexander Duyck
wrote:
>
> On Mon, Sep 14, 2020 at 6:42 AM Hans de Goede wrote:
> >
> > Hi,
> >
> > On 9/11/20 9:45 PM, David E. Box wrote:
> > > From: Alexander Duyck
> > >
> > > Add support for the Inte
On Mon, Sep 14, 2020 at 6:42 AM Hans de Goede wrote:
>
> Hi,
>
> On 9/11/20 9:45 PM, David E. Box wrote:
> > From: Alexander Duyck
> >
> > Add support for the Intel Platform Monitoring Technology crashlog
> > interface. This interface provides a few sysfs
On Wed, Sep 9, 2020 at 5:32 PM Hugh Dickins wrote:
>
> On Wed, 9 Sep 2020, Alexander Duyck wrote:
> > On Tue, Sep 8, 2020 at 4:41 PM Hugh Dickins wrote:
> > > [PATCH v18 28/32] mm/compaction: Drop locked from
> > > isolate_migratepages_block
> > > Mos
On Wed, Sep 9, 2020 at 11:24 AM Hugh Dickins wrote:
>
> On Wed, 9 Sep 2020, Alexander Duyck wrote:
> > On Tue, Sep 8, 2020 at 6:01 PM Matthew Wilcox wrote:
> > > On Mon, Aug 24, 2020 at 08:55:04PM +0800, Alex Shi wrote:
> > > > +++ b/mm/vmscan.c
> > >
On Tue, Sep 8, 2020 at 4:41 PM Hugh Dickins wrote:
>
> [PATCH v18 28/32] mm/compaction: Drop locked from isolate_migratepages_block
> Most of this consists of replacing "locked" by "lruvec", which is good:
> but please fold those changes back into 20/32 (or would it be 17/32?
> I've not yet
On Tue, Sep 8, 2020 at 6:01 PM Matthew Wilcox wrote:
>
> On Mon, Aug 24, 2020 at 08:55:04PM +0800, Alex Shi wrote:
> > +++ b/mm/vmscan.c
> > @@ -1688,10 +1688,13 @@ static unsigned long isolate_lru_pages(unsigned
> > long nr_to_scan,
> >
> > if (!TestClearPageLRU(page)) {
>
On Sun, Aug 30, 2020 at 3:00 AM Alex Shi wrote:
>
>
>
> 在 2020/8/20 上午12:50, Alexander Duyck 写道:
> > On Wed, Aug 19, 2020 at 1:11 AM Alex Shi wrote:
> >>
> >>
> >>
> >> 在 2020/8/19 下午3:57, Anshuman Khandual 写道:
> >>>
On Thu, Aug 20, 2020 at 2:58 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午10:42, Alexander Duyck 写道:
> >> It's actually changed the meaning from current func. which I had seen a
> >> bug if no relock.
> >> but after move to 5.9 kernel, I can not reprodce the b
On Thu, Aug 20, 2020 at 2:51 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午10:57, Alexander Duyck 写道:
> >>> lruvec = relock_page_lruvec_irqsave(page, lruvec, );
> >> the lock bounce is better with the patch, would you like to do further
> >> li
On Wed, Aug 19, 2020 at 1:11 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午3:57, Anshuman Khandual 写道:
> >
> >
> > On 08/19/2020 11:17 AM, Alex Shi wrote:
> >> Current pageblock_flags is only 4 bits, so it has to share a char size
> >> in cmpxchg when get set, the false sharing cause perf drop.
> >>
>
On Wed, Aug 19, 2020 at 12:54 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午12:27, Alexander Duyck 写道:
> > From: Alexander Duyck
> >
> > The release_pages function has a number of paths that end up with the
> > LRU lock having to be released and reacquired. Such
On Wed, Aug 19, 2020 at 12:52 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午12:27, Alexander Duyck 写道:
> > From: Alexander Duyck
> >
> > In isolate_lru_pages we have an exception path where if we call
> > get_page_unless_zero and that succeeds, but TestCle
On Wed, Aug 19, 2020 at 4:43 AM Matthew Wilcox wrote:
>
> On Tue, Aug 18, 2020 at 09:27:05PM -0700, Alexander Duyck wrote:
> > + /*
> > + * Page is compound. We know the order before we know if it is
> > + * on the LRU so we cannot a
On Wed, Aug 19, 2020 at 12:58 AM Alex Shi wrote:
>
>
>
> 在 2020/8/19 下午12:27, Alexander Duyck 写道:
> > From: Alexander Duyck
> >
> > The current code for move_pages_to_lru is meant to release the LRU lock
> > every time it encounters an unevictable page or a
From: Alexander Duyck
Since we are holding a reference to the page much sooner in
isolate_migratepages_block we can move the PageCompound check out of the
LRU locked section and instead just place it after get_page_unless_zero. By
doing this we can allow any of the items that might trigger
% on the will-it-scale/page_fault2 test with THP
enabled by default, however that is just some preliminary data and I still
have a number of tests left to run.
---
Alexander Duyck (5):
mm: Identify compound pages sooner in isolate_migratepages_block
mm: Drop use of test_and_set_skip
From: Alexander Duyck
The current code for move_pages_to_lru is meant to release the LRU lock
every time it encounters an unevictable page or a compound page that must
be freed. This results in a fair amount of code bulk because the lruvec has
to be reacquired every time the lock is released
From: Alexander Duyck
The only user of test_and_set_skip was isolate_migratepages_block and it
was using it after a call that was testing and clearing the LRU flag. As
such it really didn't need to be behind the LRU lock anymore as it wasn't
really fulfilling its purpose.
Since it is only
From: Alexander Duyck
In isolate_lru_pages we have an exception path where if we call
get_page_unless_zero and that succeeds, but TestClearPageLRU fails we call
put_page. Normally this would be problematic but due to the way that the
calls are ordered and the fact that we are holding the LRU
From: Alexander Duyck
The release_pages function has a number of paths that end up with the
LRU lock having to be released and reacquired. Such an example would be the
freeing of THP pages as it requires releasing the LRU lock so that it can
be potentially reacquired by __put_compound_page
On Mon, Aug 17, 2020 at 8:22 PM Wei Yang
wrote:
>
> On Mon, Aug 17, 2020 at 09:05:32AM -0700, Alexander Duyck wrote:
> >
> >
> >On 8/17/2020 2:35 AM, David Hildenbrand wrote:
> >> On 17.08.20 10:48, Wei Yang wrote:
> >> > If "page"
&& !list_is_first(>lru, list))
> + if (!list_is_first(>lru, list))
> list_rotate_to_front(>lru, list);
>
> /* release lock before waiting on report processing */
Reviewed-by: Alexander Duyck
> @@ -1691,17 +1680,34 @@ static unsigned long isolate_lru_pages(unsigned long
> nr_to_scan,
> * only when the page is being freed somewhere else.
> */
> scan += nr_pages;
> - switch (__isolate_lru_page(page, mode)) {
> +
On Sat, Aug 15, 2020 at 2:51 AM Alex Shi wrote:
>
>
>
> 在 2020/8/15 上午5:15, Alexander Duyck 写道:
> > On Fri, Aug 14, 2020 at 7:24 AM Alexander Duyck
> > wrote:
> >>
> >> On Fri, Aug 14, 2020 at 12:19 AM Alex Shi
> >> wrote:
> >>
On 8/17/2020 2:35 AM, David Hildenbrand wrote:
On 17.08.20 10:48, Wei Yang wrote:
If "page" is the list head, list_for_each_entry_safe() would stop
iteration.
Signed-off-by: Wei Yang
---
mm/page_reporting.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sun, Aug 16, 2020 at 7:11 AM Alex Shi wrote:
>
>
>
> 在 2020/8/16 下午12:17, Matthew Wilcox 写道:
> > On Sun, Aug 16, 2020 at 11:47:57AM +0800, Alex Shi wrote:
> >> Current pageblock_flags is only 4 bits, so it has to share a char size
> >> in cmpxchg when get set, the false sharing cause perf
On Fri, Aug 14, 2020 at 7:24 AM Alexander Duyck
wrote:
>
> On Fri, Aug 14, 2020 at 12:19 AM Alex Shi wrote:
> >
> >
> >
> > 在 2020/8/13 下午12:02, Alexander Duyck 写道:
> > >
> > > Since we have dropped the late abort case we can drop the code
On Fri, Aug 14, 2020 at 12:19 AM Alex Shi wrote:
>
>
>
> 在 2020/8/13 下午12:02, Alexander Duyck 写道:
> >
> > Since we have dropped the late abort case we can drop the code that was
> > clearing the LRU flag and calling page_put since the abort case will now
> >
On Wed, Aug 12, 2020 at 11:57 PM Alex Shi wrote:
>
>
>
> 在 2020/8/13 下午12:02, Alexander Duyck 写道:
> > From: Alexander Duyck
> >
> > We can drop the need for the locked variable by making use of the
> > lruvec_holds_page_lru_lock function. By doing this we can
On Thu, Aug 13, 2020 at 12:45 AM Alex Shi wrote:
>
>
>
> 在 2020/8/13 下午12:02, Alexander Duyck 写道:
> > - rcu_read_lock();
> > - lruvec = mem_cgroup_page_lruvec(page, pgdat);
> > -
> > /* If we already hold t
on the assumption that get_page_unless_zero is enough to keep a
compound page from being split up. I plan on doing some testing tomorrow,
but thought I would push these out now so that we could discuss them.
---
Alexander Duyck (3):
mm: Drop locked from isolate_migratepages_block
mm
From: Alexander Duyck
We can drop the need for the locked variable by making use of the
lruvec_holds_page_lru_lock function. By doing this we can avoid some rcu
locking ugliness for the case where the lruvec is still holding the LRU
lock associated with the page. Instead we can just use
1 - 100 of 2293 matches
Mail list logo
