linux-mm.kvack.org archive mirror
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox