From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A178BC433EF for ; Fri, 11 Mar 2022 11:54:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343886AbiCKLzH (ORCPT ); Fri, 11 Mar 2022 06:55:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230512AbiCKLzG (ORCPT ); Fri, 11 Mar 2022 06:55:06 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7667D4339D; Fri, 11 Mar 2022 03:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=QKQNUb8gG1815bo0+LJAzephXsrFMrZXGrmPtBwOo6c=; t=1646999643; x=1648209243; b=alHnBgDIHy9y0RUCRwwm0He8FSk4xcPUW9/EkiSAih21DFM 8yjhuigiX6tbzgl3M08NcjD5KiTxv9w+CXmUJX/aSYqJ1AyInOYuNm4901RQFfmqFnR6CYZlwuEc3 Hj4/kj489RxcTwk35q/BGf44Di9sAq1qrrCZFCQeK90/PGycpLm0Ntu8xqZMeNuznVFTvihU6g9Xc W3aRh+VZ+JOzxzwDMvOdb5ItDjw3PNVKrMwz596BzdCUE6CR2P2wZmHzQ7pNByEtQb1dOfGczHFbY GK9v93vvNdHsHZ6ecXRO1xFbNvE1vE7ATVeZ47RQc+3yw57RdaLI55lmMyaftxkw==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1nSdqI-00BtPi-Dc; Fri, 11 Mar 2022 12:53:58 +0100 Message-ID: <564672530e489da8872bdf1d8cdee7ce071d6a19.camel@sipsolutions.net> Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins From: Johannes Berg To: Rob Clark , David Laight Cc: Abhinav Kumar , Greg KH , "rafael@kernel.org" , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "swboyd@chromium.org" , "khsieh@codeaurora.org" , "nganji@codeaurora.org" , "seanpaul@chromium.org" , "dmitry.baryshkov@linaro.org" , "aravindh@codeaurora.org" , "freedreno@lists.freedesktop.org" Date: Fri, 11 Mar 2022 12:53:57 +0100 In-Reply-To: References: <1644349472-31077-1-git-send-email-quic_abhinavk@quicinc.com> <654d620b-9e14-c47f-b48c-762dc0bd32a1@quicinc.com> <7db7d01fcf5a3edce61161769c0e6eb1541237bf.camel@sipsolutions.net> <2add9ba7-7bc8-bd1d-1963-61e8154b0e3c@quicinc.com> <989efb15-cc5e-8f6d-c313-118f01498e33@quicinc.com> <8fa2f879e33e4e42b76e21c6fbdcb023@AcuMS.aculab.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, 2022-03-01 at 09:45 -0800, Rob Clark wrote: > On Mon, Feb 28, 2022 at 10:49 PM David Laight wrote: > > > > From: Abhinav Kumar > > > Sent: 28 February 2022 21:38 > > ... > > > We also did some profiling around how much increasing the block size > > > helps and here is the data: > > > > > > Block size cost > > > > > > 4KB 229s > > > 8KB 86s > > > > You must have an O(n^2) operation in there - find it. > > The problem is how the devcoredump/sysfs interface works, which > results in "re-rendering" the output for each block.. it's fine for > moderate size sysfs files, but scales quite badly once you get into > couple MB size sysfs files. > > It could be fixed by having some way to keep state across successive > read callbacks. I'm not sure that's true? Perhaps for dev_coredumpm(), but only if you implemented read() badly. If you have e.g. dev_coredumpsg() or dev_coredumpv() that's just a simple read from the existing buffer. johannes