From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFA8ADF78; Sun, 16 Feb 2025 16:04:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.60.130.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739721901; cv=none; b=laJ7b9zRCbXnLwEmPBDc4Uvnq4V5N3Ff3F+P4V2GeEriz9MGxWc+niuwji2KLhKwIwncwJv2WXfSi75+1IGCxOa36OV6Q06GTHb4dfnqZIo5I+cJrA7ihxbMRNeeyuBYcpbcDHUVXpwe4J+HvKXiMXjCM3vgPLJQHaEY6p1lDRs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739721901; c=relaxed/simple; bh=2ZaDVlLJ/ti9Ae9cuEdkGgHUJgEfXAaoAFiRBsExjy8=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=FcxCjgQP7wJIsCW2ciQcrLRSRyBRUWCsww7IyGIO8RJsZuO71J4ABeU7UxY+i/7+gG2ZiUiz7h3aIjGGfx3+0FtD74Ty7T1c1cW+1NsDJbB5PrD5ohVafDj4EU5P1ZV2lSXX7aTgWfVdzaFq+4mhOb900+EmKyNLML6rjJLmmcE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=cbmOVPzk; arc=none smtp.client-ip=178.60.130.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="cbmOVPzk" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Cc:To:From:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fUJitB9s5rqxO+wH4KzInz9GqX7SWy9xiRXEy3JnYmQ=; b=cbmOVPzkvpZe7FnADVf60GfkvI BD0uvz7oXu+J0pOPe4PfSClIwC+lXQvqe0YjzXDM0EfRW5eWU68e7pgqhHG8fnJFrOAI/LhhQba+M 264r5Vkki7ChhLt9RLxr9ypb6qvGOWBI3rbWYRm5PGCoE5FMk2JgUsb0EICruHhhV1UTAat99jr8O QYF4kT7LFdfSuxktOiYHT/EkP52JPEfrUsBNKxIpSlalm/Uc0dmQn5Pbq0aEQOqu5ni3osaQF7NH5 TLd6W9qyr/qQbbqzDXzdxXJpArAatp97nwYVCGrekdipUt0zRNNYxe9tVjHpngQkvej7mKMMD9Yw2 1uCDPflA==; Received: from [58.29.143.236] (helo=[192.168.1.6]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1tjh84-005DKV-DU; Sun, 16 Feb 2025 17:04:30 +0100 Message-ID: <7ea1165d-d399-4d40-ad5b-fab44e2148ca@igalia.com> Date: Mon, 17 Feb 2025 01:04:16 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next] bpf: Add a retry after refilling the free list when unit_alloc() fails From: Changwoo Min To: Alexei Starovoitov Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eddy Z , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Tejun Heo , Andrea Righi , kernel-dev@igalia.com, bpf , LKML References: <20250212084851.150169-1-changwoo@igalia.com> <4fd39e4b-f2dc-4b7d-a3be-ec3eae8d592a@igalia.com> <6632e26d-996c-432e-956f-5be178722e5b@igalia.com> Content-Language: en-US, ko-KR, en-US-large, ko In-Reply-To: <6632e26d-996c-432e-956f-5be178722e5b@igalia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello, > > What is sizeof(struct bpf_cpumask) in your system? > > In my system, sizeof(struct bpf_cpumask) is 1032. It was a wrong number. sizeof(struct bpf_cpumask) is actually 16. On 25. 2. 16. 00:16, Changwoo Min wrote: > Hello, > > On 25. 2. 15. 12:51, Alexei Starovoitov wrote: > > On Fri, Feb 14, 2025 at 1:24 AM Changwoo Min > wrote: > >> > >> Hello Alexei, > >> > >> Thank you for the comments! I reordered your comments for ease of > >> explanation. > >> > >> On 25. 2. 14. 02:45, Alexei Starovoitov wrote: > >>> On Wed, Feb 12, 2025 at 12:49 AM Changwoo Min > wrote: > >> > >>> The commit log is too terse to understand what exactly is going on. > >>> Pls share the call stack. What is the allocation size? > >>> How many do you do in a sequence? > >> > >> The symptom is that an scx scheduler (scx_lavd) fails to load on > >> an ARM64 platform on its first try. The second try succeeds. In > >> the failure case, the kernel spits the following messages: > >> > >> [   27.431380] sched_ext: BPF scheduler "lavd" disabled (runtime error) > >> [   27.431396] sched_ext: lavd: ops.init() failed (-12) > >> [   27.431401]    scx_ops_enable.isra.0+0x838/0xe48 > >> [   27.431413]    bpf_scx_reg+0x18/0x30 > >> [   27.431418]    bpf_struct_ops_link_create+0x144/0x1a0 > >> [   27.431427]    __sys_bpf+0x1560/0x1f98 > >> [   27.431433]    __arm64_sys_bpf+0x2c/0x80 > >> [   27.431439]    do_el0_svc+0x74/0x120 > >> [   27.431446]    el0_svc+0x80/0xb0 > >> [   27.431454]    el0t_64_sync_handler+0x120/0x138 > >> [   27.431460]    el0t_64_sync+0x174/0x178 > >> > >> The ops.init() failed because the 5th bpf_cpumask_create() calls > >> failed during the initialization of the BPF scheduler. The exact > >> point where bpf_cpumask_create() failed is here [1]. That scx > >> scheduler allocates 5 CPU masks to aid its scheduling decision. > > > > ... > > > >> In this particular scenario, the IRQ is not disabled. I just > > > > since irq-s are not disabled the unit_alloc() should have done: > >          if (cnt < c->low_watermark) > >                  irq_work_raise(c); > > > > and alloc_bulk() should have started executing after the first > > calloc_cpumask(&active_cpumask); > > to refill it from 3 to 64 > > Is there any possibility that irq_work is not scheduled right away on > aarch64? > > > > > What is sizeof(struct bpf_cpumask) in your system? > > In my system, sizeof(struct bpf_cpumask) is 1032. > > > > > Something doesn't add up. irq_work_queue() should be > > instant when irq-s are not disabled. > > This is not IRQ_WORK_LAZY.> Are you running PREEMPT_RT ? > > No, CONFIG_PREEMPT_RT is not set. > > Regards, > Changwoo Min > >