All of lore.kernel.org
 help / color / mirror / Atom feed
From: wangjianxing <wangjianxing@loongson.cn>
To: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm/page_alloc: add scheduling point to free_unref_page_list
Date: Fri, 11 Mar 2022 11:22:40 +0800	[thread overview]
Message-ID: <9dd723a4-64e9-feac-0f84-61c129fc85e4@loongson.cn> (raw)
In-Reply-To: <6dd8965e-3dd5-895b-641c-a04fa2b1115e@suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

>2) find out how long the tlb batches actually are and make them smaller

PAGE_SIZE is 16k other than 4k in my kernel configuration, batch count 
max is 2015.
currently MAX_GATHER_BATCH depends on PAGE_SIZE, I will make batch's max 
size smaller without depending on PAGE_SIZE.

#define MAX_GATHER_BATCH   ((PAGE_SIZE - sizeof(struct 
mmu_gather_batch)) / sizeof(void *))

On 03/10/2022 05:11 PM, Vlastimil Babka wrote:
> On 3/10/22 04:29, Andrew Morton wrote:
>> On Thu, 10 Mar 2022 10:48:41 +0800 wangjianxing<wangjianxing@loongson.cn>  wrote:
>>
>>> spin_lock will preempt_disable(), interrupt context will
>>> __irq_enter/local_bh_disable and also add preempt count with offset.
>>>
>>> cond_resched check whether if preempt_count == 0 in first and won't
>>> schedule in previous context.
>>>
>>> Is this right?
>>>
>>>
>>> With another way, could we add some condition to avoid call cond_resched
>>> in interrupt context or spin_lock()?
>>>
>>> + if (preemptible())
>>> +       cond_resched();
>>>
>> None of this works with CONFIG_PREEMPTION=n.
> Yeah I think we have at least two options.
>
> 1) check all callers, maybe realize all have enabled interrupts anyway,
> rewrite the locking to only assume those
>
> 2) find out how long the tlb batches actually are and make them smaller


[-- Attachment #2: Type: text/html, Size: 1957 bytes --]

      reply	other threads:[~2022-03-11  3:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  1:38 [PATCH 1/1] mm/page_alloc: add scheduling point to free_unref_page_list wangjianxing
2022-03-02 23:34 ` Andrew Morton
2022-03-03  2:02   ` wangjianxing
2022-03-08 16:04   ` Vlastimil Babka
2022-03-08 16:05 ` Vlastimil Babka
2022-03-08 16:19 ` Matthew Wilcox
2022-03-10  1:05   ` Andrew Morton
2022-03-10  2:48     ` wangjianxing
2022-03-10  3:29       ` Andrew Morton
2022-03-10  9:11         ` Vlastimil Babka
2022-03-11  3:22           ` wangjianxing [this message]

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=9dd723a4-64e9-feac-0f84-61c129fc85e4@loongson.cn \
    --to=wangjianxing@loongson.cn \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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.