From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from msg-2.mailo.com (msg-2.mailo.com [213.182.54.12]) (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 454CAC959; Thu, 23 Mar 2023 19:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1679600790; bh=Ofo5WnknXu2q4PHMQtHwGNgTsx9PA3GsytL7rSclMoM=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=d/RQhi09FV2kGD7zsVGy49E61BrwVVX1p8onsuoJ937QJonp0xESkL1t0xv6efXLs 6v9HL8quo3/fR0D7I9sVGtQZmExwTGNZ6A+i+nbkaCnf7g2qLRwyi233ZTlNa5pXKI 3IWFT/21lXvvaEX0neoGaJl9+cXCBpVzlNSPzYdE= Received: by b221-3.in.mailobj.net [192.168.90.23] with ESMTP via ip-20.mailobj.net [213.182.54.20] Thu, 23 Mar 2023 20:46:30 +0100 (CET) X-EA-Auth: jRldBc3fw9HBPmS2VhRtuXpKewjU9HPr0zvL+RMjtoTBXoNrOPkyuG56v9mN9SoAFgEQrrgGpYQwP1A4u5xeLZPK9L+o8cFj Date: Fri, 24 Mar 2023 01:16:26 +0530 From: Deepak R Varma To: Greg KH Cc: Julia Lawall , Alex Elder , Menna Mahmoud , outreachy@lists.linux.dev, johan@kernel.org, elder@kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH v2] staging: greybus: use inline function for macros Message-ID: References: <20230321183456.10385-1-eng.mennamahmoud.mm@gmail.com> <2e869677-2693-6419-ea25-f0cc2efcf3dd@ieee.org> <5efa6e6d-8573-31de-639a-d15b2e9deca0@ieee.org> <48674d8f-9753-780c-f37c-f83ea2855ae6@ieee.org> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Mar 23, 2023 at 06:22:55AM +0100, Greg KH wrote: > On Thu, Mar 23, 2023 at 10:35:59AM +0530, Deepak R Varma wrote: > > On Thu, Mar 23, 2023 at 05:58:02AM +0100, Greg KH wrote: > > > Nice, that shows that it is the same both ways as the compiler version > > > you are using is smart enough > > > > > > Which compiler and version is this? Does it work the same for all of > > > the supported versions we have to support (i.e. really old gcc?) > > > > > > For the most part, sysfs files are not on any sort of "fast path" so a > > > > Hello, > > Is there a guideline/documentation on how to identify if a code is part of > > fast/slow path? > > Not really, the general rule is if the code is used in a function that > is time criticial, then it is in the "fast path". > > Normally the code path for I/O or for determining what process to > schedule next is a "fast path" as you want to do the least amount of > work in the kernel so as to get the I/O to the hardware or caller, or > you want to schedule the next process faster so that it can do the real > work that is wanted. > > But for some I/O, where the hardware is the limiting factor (like slow > USB or serial connections), no matter how optimized the kernel is, the > data can not get to the user any faster because the hardware just can > not provide it, so for that, it's not really that critical. > > Note that "time critical" can change depending on the user of the system > and as hardware evolves. > > One example would be the creation of a number of sysfs entries for the > disks in the systems. On a "normal" system, creating them all is trivial > as there are not many disks. But on some "big" systems with many tens > of thousands of disks, it can become a boot time bottleneck. > > So it's usually "you know it when you see it show up on a profile", use > the perf tool to test your workload on, to see where in the kernel > things are taking up too much time so you know what needs to be made > faster. > > hope this helps, Thank you Greg. Yes, it definitely is very helpful. I sincerely appreciate the explanation and the time you took to write it in so detail. I am Obliged. Regards, Deepak. > > greg k-h