From nobody Sun Oct 5 16:15:48 2025 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1968322D786 for ; Fri, 1 Aug 2025 09:34:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754040880; cv=none; b=eDhEM1Bz531/vjiPrSXqkV9EFbvp+oBwPeE+6Ke1nl5cnCv83/hDkJysjMZOa+ebs+8PyvqeuImCkfN//mGQyt9r5+2m6m2HHx1mlYDJJwJxwEXfmtx/mBeLQfOaoEoz/ZtfX13lRoH9WgSp4HOU2hJTI+62SIp5nlpMgOTVCfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754040880; c=relaxed/simple; bh=eLYoWgXyS7q+zymmSF2I97MJ8/BJFJ8m+MpuoftRZrc=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=fGgalg3ctjy7xUcpH0NB9zLsIJtkk/gYi/mlymWdktmSGsLH3B3IVUsq2dLz2KIX++wfEoBDSppvCiO25IqGZXvTOORC/Peyz4qwF6kjgeCWxpplte4QQ7Mmu1qxYYLleHzv54RJQvUbyYrwCtmDaDACjaEOwH1MdEbJb9o19Zw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-454f428038eso12642175e9.2 for ; Fri, 01 Aug 2025 02:34:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754040876; x=1754645676; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=FILnsYkBqkvoKy9CR4yxwTy8MXJBPEpnT14mqZYoO8M=; b=WSJc/GgGvCczqz98e2k6Y+hlINp2JhBpgWvqiryG+qnvbqe7ntmyqHF/uZ8DtpyyLw 8imZB9kxCnOdEw2rKfIBp4Z9EcCxyTBpugsmslerjh0VWO5Od3SpQik+eO5DFneBmUen cRnlRu/AH/uKIweL4zbq45E2xStlz6VW6HepNs2Cwst5EXhg6nZCFWQxYxhW8wylwuwR mcgkdLbpnHaaCCSBVJKL0vC/kjbGFAsVulytS5YZS2u/LA0q28/QA2V1h8RxopxNPp9C PNqZf+1RZwuGFZDRWFbIsPqDpQEdnncLKuQ/xT3rkKs+3ltSjdBVxAMcMXxerG8MnsvU 60Ew== X-Gm-Message-State: AOJu0YxASq5SBZL+LxzvAjUkHrI0tW470JdqIWECRyGi47Jor6nEm0ju 6uJddkLlaehczapp9AS9kS0NnTlnhQyq+0IcF9xPkfX1ECjDejLmCfgaCHbBVQ== X-Gm-Gg: ASbGncsMp9hmzfNNF5U13vxj82gExfX6R+oXZUyvMdHXhoSmgyvbJcEm4f1fE8HOdVL 0EKMBwXM0Irkwaumiu8RDP72WK6Tnf95HwlG2Sk6hyC3kxXzcxDpOZJay4fjaKkvDrrd2/KamTv 9j369Fc75iiumJNf9j/2qYQdjkRO4VoMTKKJd/qEXy4L1EjvkTe5x48vRvJ3rdTUKbEcHKsAmG3 RBDbpAeje39NfCnwsMl5c67gCzT1AvBxhE+/777rowj6wwkKYWqEbWXH/sIDqIwFkaUEoFoZ6fN pDrdX3nlIkuVYfux6+8SUTDoBkX5XfZfe5SVXXNZNxCnWHEYlWRlyfMaetjmczoeyqSrTA/M5GS UeAsxk/SXSwLAeAFlENZyT1NtedA75Ibt0CFgxNkEC0mFIwyAAHJS2DIfWfvYpr73OhdE7g1gR2 tn39awiorv X-Google-Smtp-Source: AGHT+IEx26GTyTeV7UqTBTcD0yrUFM6lJfcf81YmMLBZZ2BTy+3czlzjK8pyCTLto081NB9eDog9pg== X-Received: by 2002:a05:600c:310d:b0:450:d01f:de6f with SMTP id 5b1f17b1804b1-458aa32e7a4mr16743345e9.15.1754040875850; Fri, 01 Aug 2025 02:34:35 -0700 (PDT) Received: from [192.168.1.101] (croy-25-b2-v4wan-169464-cust2304.vm24.cable.virginm.net. [92.236.41.1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458a7c91c0esm36150775e9.11.2025.08.01.02.34.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Aug 2025 02:34:35 -0700 (PDT) Message-ID: <6dec5463-3ef5-4085-ad4f-6c2792f85ace@linux.com> Date: Fri, 1 Aug 2025 10:34:34 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Linux Kernel Mailing List , kernelnewbies@kernelnewbies.org From: Lucas Tanure Subject: Linux Device Performance Analyses - Where are my cylces? Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Hey there, I'm a kernel developer working on an Android device with a 5.10 kernel.=20 I'm trying to improve performance, and to do that, I need to figure out=20 exactly where the CPU is spending its time. Our vendor provides a generic Android BSP, so the system is likely=20 running many unnecessary processes for things like GPS and phone calls=20 that my device doesn't even need. Since I don't have a good handle on=20 all these processes, I want to create a detailed breakdown of all the=20 tasks, workqueues, IRQs, kernel threads, softIRQs, and tasklets running=20 and measure the CPU time each one is using. To do this, I've been using kernel traces with the following events: task:task_newtask sched:sched_process_fork sched:sched_process_exec sched:sched_process_exit sched:sched_switch=20 irq:irq_handler_entry irq:irq_handler_exit irq:softirq_entry=20 irq:softirq_exit workqueue:workqueue_execute_start=20 workqueue:workqueue_execute_end syscalls:sys_enter_execve=20 syscalls:sys_exit_execve syscalls:sys_enter_execveat=20 syscalls:sys_exit_execveat However, the trace logs don't provide the full picture. For example,=20 when a new process is executed, the logs don't specify the script being=20 run. The sched_switch event tells me which PID is being executed, but=20 multiple processes can originate from the same binary, so it's hard to=20 distinguish them. To solve this, I've developed a patch for the do_execveat_common=20 function to log all new processes along with their full command lines. I=20 plan to use this patch with a Python script to parse the logs and=20 generate a report on CPU usage. My main questions are: - Is my patch correct? When I log the new process, do current->pid and=20 argv refer to the same new process? - It feels like logging new processes with their command lines is a=20 fundamental requirement for this kind of analysis. Am I missing a better=20 or more standard way of doing this? - I don't want to reinvent the wheel, so if there's a better way to=20 analyze kernel performance on a device, I'd love to hear about it. After looking into other methods like eBPF and kprobes, I found that=20 this patch is the most straightforward way to get the information I need. Any insights would be greatly appreciated! Thanks Lucas Tanure diff --git a/fs/exec.c b/fs/exec.c index 6e1f8628ab9c..ab797ba0571c 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -513,6 +513,49 @@ static int bprm_stack_limits(struct linux_binprm *bprm) return 0; } +static char* str_cmdline(int argc, struct user_arg_ptr argv, struct=20 linux_binprm *bprm) +{ + char *buf =3D (char *)get_zeroed_page(GFP_KERNEL); + ssize_t pos =3D 0; + int arg; + + for (arg =3D 0; arg < argc; arg++) { + const char __user *str; + int len; + + str =3D get_user_arg_ptr(argv, arg); + if (IS_ERR(str)) + goto free_page; + + // this includes a final null. + len =3D strnlen_user(str, MAX_ARG_STRLEN); + if (!len) + goto free_page; + + if (!valid_arg_len(bprm, len)) + goto free_page; + + if (pos + len >=3D PAGE_SIZE) + break; // Return the command line up to a page + + len -=3D 1; // Don't copy the final null. + if (copy_from_user(buf+pos, str, len)) + goto free_page; + + pos +=3D len; + + if (arg < argc - 1) + buf[pos++] =3D ' '; + } + + return buf; + +free_page: + free_page((unsigned long)buf); + + return NULL; +} + /* * 'copy_strings()' copies argument/environment strings from the old * processes's memory to the new process's stack. The call to=20 get_user_pages() @@ -1874,6 +1917,7 @@ static int do_execveat_common(int fd, struct=20 filename *filename, { struct linux_binprm *bprm; int retval; + char *cmdline; if (IS_ERR(filename)) return PTR_ERR(filename); @@ -1943,6 +1987,15 @@ static int do_execveat_common(int fd, struct=20 filename *filename, bprm->argc =3D 1; } + cmdline =3D str_cmdline(bprm->argc, argv, bprm); + pr_info("%s pid: %d, comm: %s # filename: %s # cmdline: %s\n", __func__, + current->pid, + current->comm, + bprm->filename, + cmdline ? cmdline : "NULL"); + if (cmdline) + free_page((unsigned long)cmdline); + retval =3D bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm);