[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1e9b2d55-09cf-422e-a3f5-2f6084e675c3@quicinc.com>
Date: Wed, 4 Oct 2023 16:15:44 +0530
From: Sarthak Garg <quic_sartgarg@...cinc.com>
To: Wenchao Chen <wenchao.chen666@...il.com>
CC: Ulf Hansson <ulf.hansson@...aro.org>,
"Kamasali Satyanarayan (Consultant) (QUIC)"
<quic_kamasali@...cinc.com>,
"avri.altman@....com" <avri.altman@....com>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"shawn.lin@...k-chips.com" <shawn.lin@...k-chips.com>,
"merez@...eaurora.org" <merez@...eaurora.org>,
"s.shtylyov@....ru" <s.shtylyov@....ru>,
"huijin.park@...sung.com" <huijin.park@...sung.com>,
"briannorris@...omium.org" <briannorris@...omium.org>,
"digetx@...il.com" <digetx@...il.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Veerabhadrarao Badiganti" <vbadigan@...eaurora.org>,
Shaik Sajida Bhanu <sbhanu@...eaurora.org>
Subject: Re: [PATCH V1] mmc: core: Add partial initialization support
On 9/28/2023 8:50 AM, Wenchao Chen wrote:
> On Tue, 26 Sept 2023 at 18:41, Sarthak Garg <quic_sartgarg@...cinc.com> wrote:
>>
>> On 6/16/2022 4:18 AM, Ulf Hansson wrote:
>>> On Tue, 24 May 2022 at 07:37, Sarthak Garg (QUIC)
>>> <quic_sartgarg@...cinc.com> wrote:
>>>> Hi Ulf,
>>>>
>>>> Please find the gains seen on micron and kingston eMMC parts below with partial initialization feature (These are the averaged numbers) :
>>>>
>>>> 1) Micron eMMC (ManfID 0x13)
>>>>
>>>> Partial init Full Init
>>>>
>>>> a) _mmc_resume: _mmc_resume :
>>>>
>>>> Total time : 62ms Total time : 84ms
>>>> (Decrease % from full init = ~26%)
>>> Alright, so we gained around 22ms. Not too bad.
>>>
>>>> Breakup :
>>>> mmc_claim_host_time: 0.2ms mmc_claim_host_time: 0.1ms
>>>> mmc_power_up_time: 33ms mmc_power_up_time: 33ms
>>>> mmc_sleepawake_time: 28ms mmc_init_card_time: 50ms
>>>> mmc_partial_init_time: 1ms
>>>>
>>>> b) _mmc_suspend: _mmc_suspend:
>>>>
>>>> Total time: 5ms Total time: 7.5ms
>>>> mmc_claim_host_time: 0.5ms mmc_claim_host_time: 1ms
>>>> mmc_flush_cache_time : 1.5 ms mmc_flush_cache_time : 2.5 ms
>>>> mmc_sleep_time: 1.5ms mmc_sleep_time: 2ms
>>>> mmc_power_off_time: 1.5ms mmc_power_off_time: 1.5ms
>>> The suspend time shouldn't really differ. Or is there a reason for this?
>>
>> I think this could be due to run to run variation as we can see
>> mmc_claim_host and mmc_flush_cache itself taking some extra 1ms.
>>
>>
> Hi Sarthak
>
> I have a question.
> 1.What is the difference between Partial init and Full Init on SOC
> power consumption?
> 2.Partial init and Full init improve IO performance?
> 3.Could you share the test methods if you want?
No difference in SOC power consumption between the two .. it just
improves the resume latency as mentioned in commit text.
Partial init and Full init only improves the resume latency and no IO
performance impact.
We don't have any such test methods instead just evaluated the resume
delays using ftraces.
Thanks,
Sarthak
>
>>>> 2) Kingston eMMC (ManfID 0x70)
>>>>
>>>> Partial init Full Init
>>>>
>>>> a) _mmc_resume: _mmc_resume :
>>>> Total time : 46ms Total time : 62ms
>>>> (Decrease % from full init = ~25%)
>>>>
>>>> Breakup :
>>>> mmc_claim_host_time: 0.2ms mmc_claim_host_time: 0.2ms
>>>> mmc_power_up_time: 30ms mmc_power_up_time: 30ms
>>>> mmc_sleepawake_time: 14ms mmc_init_card_time: 31ms
>>>> mmc_partial_init_time: 2ms
>>>>
>>>>
>>>> b) _mmc_suspend: _mmc_suspend:
>>>> Total time : 5ms Total: 5ms
>>>>
>>>> Breakup :
>>>> mmc_claim_host_time: 0.5ms mmc_claim_host_time: 0.5ms
>>>> mmc_flush_cache_time : 1.5 ms mmc_flush_cache_time : 1.5 ms
>>>> mmc_sleep_time: 1.5ms mmc_sleep_time: 1ms
>>>> mmc_power_off_time: 1.5ms mmc_power_off_time: 1.5ms
>>>>
>>>> Did some minor modifications as well to this patchset as per avri's comment which I'll post as V2.
>>>> Please let me know your inputs about these numbers.
>>> Thanks for posting these numbers, much appreciated! Please try to
>>> include some of the data as part of the commit message as I think it's
>>> valuable information.
>>>
>>> When it comes to reviewing the code, I am awaiting your v2 then.
>>>
>>> [...]
>>>
>>> Kind regards
>>> Uffe
>> Sure will add this data to the commit text in V2.
>>
>>
Powered by blists - more mailing lists