> On Mar 18, 2021, at 11:10 PM, Peter Zijlstra wrote:
>
> On Thu, Mar 18, 2021 at 08:59:44AM -0400, Phil Auld wrote:
>> I admit to not having followed all the history of this patch set. That
>> said, when I see the above I just think your quota is too low for your
>> workload.
>
> This.
>
>>
> On Mar 19, 2021, at 8:39 PM, changhuaixin
> wrote:
>
>
>
>> On Mar 18, 2021, at 11:05 PM, Peter Zijlstra wrote:
>>
>> On Thu, Mar 18, 2021 at 09:26:58AM +0800, changhuaixin wrote:
>>>> On Mar 17, 2021, at 4:06 PM, Peter Zijlstra wrote:
>
> On Mar 18, 2021, at 8:59 PM, Phil Auld wrote:
>
> On Thu, Mar 18, 2021 at 09:26:58AM +0800 changhuaixin wrote:
>>
>>
>>> On Mar 17, 2021, at 4:06 PM, Peter Zijlstra wrote:
>>>
>>> On Wed, Mar 17, 2021 at 03:16:18PM +0800, changhuaixin
> On Mar 18, 2021, at 11:05 PM, Peter Zijlstra wrote:
>
> On Thu, Mar 18, 2021 at 09:26:58AM +0800, changhuaixin wrote:
>>> On Mar 17, 2021, at 4:06 PM, Peter Zijlstra wrote:
>
>>> So what is the typical avg,stdev,max and mode for the workloads where y
> On Mar 17, 2021, at 4:06 PM, Peter Zijlstra wrote:
>
> On Wed, Mar 17, 2021 at 03:16:18PM +0800, changhuaixin wrote:
>
>>> Why do you allow such a large burst? I would expect something like:
>>>
>>> if (burst > quote)
>>>
> On Mar 16, 2021, at 5:54 PM, Peter Zijlstra wrote:
>
> On Tue, Mar 16, 2021 at 12:49:28PM +0800, Huaixin Chang wrote:
>> @@ -8982,6 +8983,12 @@ static int tg_set_cfs_bandwidth(struct task_group
>> *tg, u64 period, u64 quota)
>> if (quota != RUNTIME_INF && quota > max_cfs_runtime)
>>
> On Mar 10, 2021, at 9:04 PM, Peter Zijlstra wrote:
>
> On Thu, Jan 21, 2021 at 07:04:51PM +0800, Huaixin Chang wrote:
>> Accumulate unused quota from previous periods, thus accumulated
>> bandwidth runtime can be used in the following periods. During
>> accumulation, take care of runtime ove
> On Mar 10, 2021, at 7:11 PM, Odin Ugedal wrote:
>
> Hi,
>
>> If there are cases where the "start bandwidth" matters, I think there is
>> need to expose the
>> "start bandwidth" explicitly too. However, I doubt the existence of such
>> cases from my view
>> and the two examples above.
>
>
Hi，
Sorry for my late reply.
> On Feb 9, 2021, at 9:17 PM, Odin Ugedal wrote:
>
>
> Hi! This looks quite useful, but I have a few quick thoughts. :)
>
> I know of a lot of people who would love this (especially some
> Kubernetes users)! I really like how this allow users to use cfs
> in a mor
> On Jan 21, 2021, at 7:04 PM, Huaixin Chang
> wrote:
>
> Changelog
>
> v3:
> 1. Fix another issue reported by test robot.
> 2. Update docs as Randy Dunlap suggested.
>
> v2:
> 1. Fix an issue reported by test robot.
> 2. Rewriting docs. Appreciate any further suggestions or help.
>
> The
> On Dec 21, 2020, at 9:53 PM, changhuaixin
> wrote:
>
>
>
>> On Dec 17, 2020, at 9:36 PM, Peter Zijlstra wrote:
>>
>> On Thu, Dec 17, 2020 at 03:46:17PM +0800, Huaixin Chang wrote:
>>> In this patch, we introduce the notion of CFS bandwid
> On Dec 17, 2020, at 9:36 PM, Peter Zijlstra wrote:
>
> On Thu, Dec 17, 2020 at 03:46:17PM +0800, Huaixin Chang wrote:
>> In this patch, we introduce the notion of CFS bandwidth burst. Unused
>> "quota" from pervious "periods" might be accumulated and used in the
>> following "periods". The m
Hi，Ingo
This patchset reverts the hacks from patchset v1. Also it includes some other
fixes upon v1 as suggested.
Will you please have a look at this?
The previous links are:
https://lore.kernel.org/lkml/20200724135531.gb648...@gmail.com/
Thanks,
huaixin
> On Aug 7, 2020, at 12:17 PM, Huaixin
> On Aug 6, 2020, at 11:08 PM, Ingo Molnar wrote:
>
>
> * changhuaixin wrote:
>
>> Hi, Ingo
>>
>> Another way to write SHT_PROGBITS is using elf_create_section to write
>> orc_lookup table headers, when orc_unwind_ip table and orc_unwind table are
Hi, Ingo
Another way to write SHT_PROGBITS is using elf_create_section to write
orc_lookup table headers, when orc_unwind_ip table and orc_unwind table are
written. Is this a better solution?
diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
index 3f98dcfbc177..860d4dcec8e6 100644
> On Jul 24, 2020, at 9:53 PM, Ingo Molnar wrote:
>
>
> * Huaixin Chang wrote:
>
>> Since orc tables are already sorted by sorttable tool, let us move
>> building of fast lookup table into sorttable tool too. This saves us
>> 6380us from boot time under Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.5
Hi Josh, will you please have a look at this patchset?
There might be another way to set SHT_PROGBITS of section .orc_lookup by
writing section headers when orc_unwind and orc_unwind_ip tables are writen. It
might be as follows:
diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
ind
> On Jun 2, 2020, at 1:38 AM, Josh Poimboeuf wrote:
>
> On Sun, May 31, 2020 at 01:26:54PM +0800, changhuaixin wrote:
>> It turned out to be an alignment problem. If sh_size of previous section
>> orc_unwind is not 4-byte aligned, sh_offset of the following orc_looku
Thanks for your kindly reply. Let me have a check.
> On May 23, 2020, at 2:28 AM, Josh Poimboeuf wrote:
>
> On Wed, Apr 29, 2020 at 02:46:24PM +0800, Huaixin Chang wrote:
>> Move building of fast lookup table from boot to sorttable tool. This saves us
>> 6380us boot time on Intel(R) Xeon(R) CPU
> On Apr 29, 2020, at 4:49 PM, Peter Zijlstra wrote:
>
> On Wed, Apr 29, 2020 at 02:46:24PM +0800, Huaixin Chang wrote:
>> Move building of fast lookup table from boot to sorttable tool. This saves us
>> 6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores.
>
> And what do
20 matches
Mail list logo
