The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl is
generally appropriate, they do not have an identical
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl is
generally appropriate, they do not have an identical
On Thu, 12 Sep 2024, Reinette Chatre wrote:
> The MBA test incrementally throttles memory bandwidth, each time
> followed by a comparison between the memory bandwidth observed
> by the performance counters and resctrl respectively.
>
> While a comparison between performance count
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl is
generally appropriate, they do not have an identical
3 AM, Ilpo Järvinen wrote:
> > > > > > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > > > > > On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
> > > > > > > > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> > > > > > > >
Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl
4:42 AM, Ilpo Järvinen wrote:
> > > > > > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> > > > > >
> > > > > > > The MBA test incrementally throttles memory bandwidth, each time
> > > > > > > follow
throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl is
generally appropriate, they do not have an identical view of
memory bandwidth. For
gt; > > The MBA test incrementally throttles memory bandwidth, each time
> > > > > followed by a comparison between the memory bandwidth observed
> > > > > by the performance counters and resctrl respectively.
> > > > >
> > > > >
Hi Ilpo,
On 9/4/24 4:43 AM, Ilpo Järvinen wrote:
On Fri, 30 Aug 2024, Reinette Chatre wrote:
On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory
On Fri, 30 Aug 2024, Reinette Chatre wrote:
> On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
> > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> >
> > > The MBA test incrementally throttles memory bandwidth, each time
> > > followed by a comparison between the memor
From: Chunguang Xu
CLASS_RT will preempt other classes, which may starve. At
present, CLASS_IDLE has alleviated the starvation problem
through the minimum bandwidth mechanism. Similarly, we
should do the same for CLASS_BE.
Signed-off-by: Chunguang Xu
---
block/bfq-iosched.c | 6 --
block
have done some reading on queueing theory and done some problem
definition.
Divide real time into discrete periods as cfs_b does. Assume there are m
cgroups using
CFS Bandwidth Control. During each period, the i-th cgroup demands u_i CPU time,
where we assume u_i is under some distribution(expo
This configures the Sparx5 calendars according to the bandwidth
requested in the Device Tree nodes.
It also checks if the total requested bandwidth is within the
specs of the detected Sparx5 models limits.
Signed-off-by: Steen Hegelund
Signed-off-by: Bjarni Jonasson
Signed-off-by: Lars Povlsen
When the video usecase have macro blocks per sec which is more than
supported, keep the required bus bandwidth as the maximum supported.
Signed-off-by: Vikash Garodia
---
drivers/media/platform/qcom/venus/pm_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
On Tue, 2021-03-30 at 16:06 +0800, Ikjoon Jang wrote:
> Software bandwidth checking logics used by xhci-mtk puts
> a quite heavy constraints to TT periodic endpoint allocations.
>
> This patch provides a relaxed bandwidth calculation by
> - Allowing multiple periodic transac
The remainder of the last bandwidth bugdget is wrong,
it's the value alloacted in last bugdget, not unused.
Reported-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhc
Software bandwidth checking logics used by xhci-mtk puts
a quite heavy constraints to TT periodic endpoint allocations.
This patch provides a relaxed bandwidth calculation by
- Allowing multiple periodic transactions in a same microframe
for a device with multiple interrupt endpoints.
- Using
This series is for supporting typical full speed USB audio headsets
with speaker, microphone, and control knobs together.
With current implementation, such a device cannot be configured
due to xhci-mtk's bandwidth allocation failure even when there's
enough bandwidth available.
Ikjo
From: Chunguang Xu
CLASS_RT will preempt other classes, which may starve. At
present, CLASS_IDLE has alleviated the starvation problem
through the minimum bandwidth mechanism. Similarly, we
should do the same for CLASS_BE.
Signed-off-by: Chunguang Xu
---
block/bfq-iosched.c | 6 --
block
ould suggest you pick your runtime around 200%
>> to get that P95 and then allow a full period burst to get your P99, but
>> that same RT theory would also have you calculate the resulting
>> interference and see if that works with the rest of the system...
>>
>
> I am
wrote:
>>>
>>>>> Why do you allow such a large burst? I would expect something like:
>>>>>
>>>>> if (burst > quote)
>>>>> return -EINVAL;
>>>>>
>>>>> That limits the variance in the syst
27;t
provide
the desired calculation now. But I'd like to try and do some reading if that is
needed.
> 16 times is horrific.
So can we decide on a more relative value now? Or is the interference
probabilities still the
missing piece?
Is the paper you mentioned about called "Insensitivity results in statistical
bandwidth sharing",
or some related ones on statistical bandwidth results under some kind of
fairness?
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.
> The burst (mis?)feature seems to be a way to bypass the quota. And it
>
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 you
> > find
> > you need this?
> >
> > I would really like to put a limit on the burst. IMO a workload
t something like:
> >>>
> >>> if (burst > quote)
> >>> return -EINVAL;
> >>>
> >>> That limits the variance in the system. Allowing super long bursts seems
> >>> to defeat the entire purpose of bandwidth contr
18.03.2021 12:31, Michał Mirosław пишет:
>> static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
>> @@ -2430,6 +2781,7 @@ static const struct tegra_dc_soc_info
>> tegra194_dc_soc_info = {
>> .has_nvdisplay = true,
>> .wgrps = tegra194_dc_wgrps,
>> .num_wgrps = ARRAY_SI
* See the comment related to !crtc->state->active above,
> + * which explains why bandwidths need to be updated when
> + * CRTC is turning ON.
> + */
> + if (new_avg_bw == old_avg_bw && new_peak_bw == old_peak_bw
return -EINVAL;
>>>
>>> That limits the variance in the system. Allowing super long bursts seems
>>> to defeat the entire purpose of bandwidth control.
>>
>> I understand your concern. Surely large burst value might allow super
>> long bursts thus pre
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Changelog:
v16: - Implemented suggestions that were given by Michał Mirosław to v15
per long bursts seems
> > to defeat the entire purpose of bandwidth control.
>
> I understand your concern. Surely large burst value might allow super
> long bursts thus preventing bandwidth control entirely for a long
> time.
>
> However, I am afraid it is hard to decid
&& quota > max_cfs_runtime)
>> return -EINVAL;
>>
>> +/*
>> + * Bound burst to defend burst against overflow during bandwidth shift.
>> + */
>> +if (burst > max_cfs_runtime)
>> +return -EINVAL;
>
>
negative impact on
>>> +* other memory clients, hence we will request a higher bandwidth
>>> +* since latency depends on bandwidth. This allows to prevent memory
>>> +* FIFO underflows for a large plane downscales, meanwhile allowing
>>
On Fri, Mar 12, 2021 at 09:54:33PM +0800, changhuaixin wrote:
> > On Mar 10, 2021, at 9:04 PM, Peter Zijlstra wrote:
> > There's already an #ifdef block that contains that bandwidth_slice
> > thing, see the previous hunk, so why create a new #ifdef here?
> >
> > Also, personally I think percenta
_group *tg, u64 period, u64 runtime);
@@ -8989,10 +8989,10 @@ static int tg_set_cfs_bandwidth(struct t
if (quota != RUNTIME_INF && quota > max_cfs_runtime)
return -EINVAL;
- /*
-* Bound burst to defend burst against overflow during bandwidth shift.
-
Hi!
> From: Greg Kroah-Hartman
>
> From: Bjorn Helgaas
Dup.
> Remove the bandwidth change notifications for now. Hopefully we can add
> this back when we have a better understanding of why this happens and how
> we can make the messages useful instead of overwhelming.
T
gt; + /*
> + * Bound burst to defend burst against overflow during bandwidth shift.
> + */
> + if (burst > max_cfs_runtime)
> + return -EINVAL;
Why do you allow such a large burst? I would expect something like:
if (burst > quote)
I can't make sense of patch 1 and 2 independent of one another. Why the
split?
On Tue, Mar 16, 2021 at 12:49:28PM +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 maximum amount of accum
On Tue, Mar 16, 2021 at 12:49:28PM +0800, Huaixin Chang wrote:
> In this patch, we introduce the notion of CFS bandwidth burst. Unused
Documentation/process/submitting-patches.rst:instead of "[This patch] makes
xyzzy do frotz" or "[I] changed xyzzy
Accumulate unused quota from previous periods, thus accumulated
bandwidth runtime can be used in the following periods. During
accumulation, take care of runtime overflow. Previous non-burstable
CFS bandwidth controller only assign quota to runtime, that saves a lot.
A sysctl parameter
into cpu.stat file:
nr_burst: number of periods bandwidth burst occurs
burst_time: cumulative wall-time that any cpus has
used above quota in respective periods
Co-developed-by: Shanpei Chen
Signed-off-by: Shanpei Chen
Signed-off-by: Huaixin Chang
---
kernel/sched/core.c | 14
Basic description of usage and effect for CFS Bandwidth Control Burst.
Co-developed-by: Shanpei Chen
Signed-off-by: Shanpei Chen
Signed-off-by: Huaixin Chang
---
Documentation/admin-guide/cgroup-v2.rst | 16 +
Documentation/scheduler/sched-bwc.rst | 64
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 maximum amount of accumulated bandwidth is
bounded by "burst". And the maximun amount of CPU
Changelog:
v4:
- Adjust assignments in tg_set_cfs_bandwidth(), saving unnecessary
assignemnts when quota == RUNTIME_INF.
- Getting rid of sysctl_sched_cfs_bw_burst_onset_percent, as there seems
no justification for both controlling start bandwidth and a percent
way.
- Comment improvement in
15.03.2021 01:31, Michał Mirosław пишет:
> On Thu, Mar 11, 2021 at 08:22:54PM +0300, Dmitry Osipenko wrote:
>> Display controller (DC) performs isochronous memory transfers, and thus,
>> has a requirement for a minimum memory bandwidth that shall be fulfilled,
>> otherwise f
From: Greg Kroah-Hartman
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe
From: Greg Kroah-Hartman
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe
On Thu, Mar 11, 2021 at 08:22:54PM +0300, Dmitry Osipenko wrote:
> Display controller (DC) performs isochronous memory transfers, and thus,
> has a requirement for a minimum memory bandwidth that shall be fulfilled,
> otherwise framebuffer data can't be fetched fast enough and this
> 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
>> accumul
> 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
&
From: Chunguang Xu
rt_class will preempt other classes, which may cause other
classes to starve to death. At present, idle_class has
alleviated the starvation problem through the minimum
bandwidth mechanism. Similarly, we should do the same for
be_class.
Signed-off-by: Chunguang Xu
---
block
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Changelog:
v15: - Corrected tegra_plane_icc_names[] NULL-check that was partially lost
by
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
11.03.2021 20:06, Dmitry Osipenko пишет:
> +static const char * const tegra_plane_icc_names[TEGRA_DC_LEGACY_PLANES_NUM]
> = {
> + "wina", "winb", "winc", "", "", "", "cursor",
> +};
> +
> +int tegra_plane_interconnect_init(struct tegra_plane *plane)
> +{
> + const char *icc_name = tegra_pl
11.03.2021 20:06, Dmitry Osipenko пишет:
> This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
> which is done using interconnect framework. It fixes display corruption that
> happens due to insufficient memory bandwidth.
>
> Changelog:
>
> v14: - M
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Changelog:
v14: - Made improvements that were suggested by Michał Mirosław to v13
On Thu, Jan 21, 2021 at 07:04:53PM +0800, Huaixin Chang wrote:
> Basic description of usage and effect for CFS Bandwidth Control Burst.
>
> Signed-off-by: Huaixin Chang
> Signed-off-by: Shanpei Chen
Guess :-)
> +Sometimes users might want a group to burst without accumu
On Thu, Jan 21, 2021 at 07:04:52PM +0800, Huaixin Chang wrote:
> Introduce statistics exports for the burstable cfs bandwidth
> controller.
>
> The following exports are included:
>
> current_bw: current runtime in global pool
> nr_burst: number of periods bandwidth burs
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 overflow. Previous non-burstable
> CFS bandwidth con
On Thu, Jan 21, 2021 at 07:04:50PM +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 maximum amount of accum
On Tue, Jan 26, 2021 at 06:18:59PM +0800, changhuaixin wrote:
> Ping, any new comments on this patchset? If there're no other
> concerns, I think it's ready to be merged?
I only found this by accident...
Thread got lost because you're posting new series as replies to older
series. Please don't do
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.
Yeah, I don't think the
ous memory transfers, and thus,
>>>> has a requirement for a minimum memory bandwidth that shall be fulfilled,
>>>> otherwise framebuffer data can't be fetched fast enough and this results
>>>> in a DC's data-FIFO underflow that follows by a visua
From: Chunguang Xu
From: Chunguang Xu
rt_class will preempt other classes, which may cause other
classes to starve to death. At present, idle_class has
alleviated the starvation problem through the minimum
bandwidth mechanism. Similarly, we should do the same for
be_class.
Signed-off-by
Extract a function to load/unload bandwidth info, and remove
a dummy check of TT offset.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/usb/host/xhci-mtk-sch.c | 37 ++---
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host
Rebuild the function get_bw_index(), get the bandwidth domain
directly instead its index of domain array.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/usb/host/xhci-mtk-sch.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked
endpoints")
Cc: stable
Signed-o
= HS_BW_BOUNDARY;
+ break;
+ }
+
+ return boundary;
+}
+
/*
* get the index of bandwidth domains array which @ep belongs to.
*
@@ -579,13 +598,7 @@ static int check_sch_bw(struct usb_device *udev,
break;
}
- if (udev->sp
rement for a minimum memory bandwidth that shall be fulfilled,
> >> otherwise framebuffer data can't be fetched fast enough and this results
> >> in a DC's data-FIFO underflow that follows by a visual corruption.
[...]
> >> + /*
> >> + * Horizonta
Rebuild the function get_bw_index(), get the bandwidth domain
directly instead its index of domain array.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk
Extract a function to load/unload bandwidth info, and remove
a dummy check of TT offset.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 37 ++---
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked
endpoints")
Cc: stable
Signed-o
;
+ break;
+ }
+
+ return boundary;
+}
+
/*
* get the index of bandwidth domains array which @ep belongs to.
*
@@ -579,13 +598,7 @@ static int check_sch_bw(struct usb_device *udev,
break;
}
- if (udev->speed == USB_SPEED_SUPER_P
04.03.2021 02:08, Michał Mirosław пишет:
> On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
>> Display controller (DC) performs isochronous memory transfers, and thus,
>> has a requirement for a minimum memory bandwidth that shall be fulfilled,
>> otherwise f
On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
> Display controller (DC) performs isochronous memory transfers, and thus,
> has a requirement for a minimum memory bandwidth that shall be fulfilled,
> otherwise framebuffer data can't be fetched fast enough and this
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Tegra memory drivers already got the interconnect API support and DRM patches
were a part of the
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also
= do_div(burst, 100) *
>> +sysctl_sched_cfs_bw_burst_onset_percent;
>> +
>> +cfs_b->runtime += burst_onset;
>> +cfs_b->runtime = min(max_cfs_runtime, cfs_b->runtime);
>> +}
>
> I saw a comment about this behav
On Mon, Feb 8, 2021 at 11:27 AM Chunfeng Yun wrote:
>
> When the USB headset is plug into an external hub, sometimes
> can't set config due to not enough bandwidth, so need improve
> LS/FS INT/ISOC bandwidth scheduling with TT.
>
> Fixes: 08e469de87a2 ("usb:
. Given that it's mostly straight forward extension on
an existing interface, things looks fine from cgroup side; however, please
do add cgroup2 interface and documentation. One thing which has bene
bothersome about the bandwidth interface is that we're exposing
implementation details (win
cfs_b->runtime = min(max_cfs_runtime, cfs_b->runtime);
> + }
I saw a comment about this behavior, but I think this can lead to a bit of
confusion. If sysctl_sched_cfs_bw_burst_onset_percent=0, the amount of
bandwidth when the first process starts up will depend on the time between
From: Ikjoon Jang
commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280 upstream.
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
drop_endpoint() to handle its own sw bandwidth management.
It stores bandwidth data into an internal table every time
add_endpoint() is called, and
From: Chunfeng Yun
commit 54f6a8af372213a254af6609758d99f7c0b6b5ad upstream.
For those unchecked endpoints, we don't allocate bandwidth for
them, so no need free the bandwidth, otherwise will decrease
the allocated bandwidth.
Meanwhile use xhci_dbg() instead of dev_dbg() to print log
From: Chunfeng Yun
commit 54f6a8af372213a254af6609758d99f7c0b6b5ad upstream.
For those unchecked endpoints, we don't allocate bandwidth for
them, so no need free the bandwidth, otherwise will decrease
the allocated bandwidth.
Meanwhile use xhci_dbg() instead of dev_dbg() to print log
From: Ikjoon Jang
commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280 upstream.
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
drop_endpoint() to handle its own sw bandwidth management.
It stores bandwidth data into an internal table every time
add_endpoint() is called, and
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with
multi-TT")
Signed-off-by: Yaqii Wu
> static int test_metric_group(void)
> {
> double ratio1, ratio2;
> @@ -353,5 +376,6 @@ int test__parse_metric(struct test *test __maybe_unused,
> int subtest __maybe_unu
> TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
> TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
> TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
> + TEST_ASSERT_VAL("Memory bandwidth", test_memory_bandwidth() == 0);
> return 0;
> }
> --
> 2.26.2
>
From: Bjorn Helgaas
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also seem to
generate these messages.
We don't know why the
thread petered out with no resolution.
If the bandwidth change notifications are important to somebody,
please speak up, preferably with a patch that makes the notifications
disabled by default and adds a parameter to enable them (or some other
strategy that makes sense).
I think these are
gt; > > AFAICT, this thread petered out with no resolution.
> > > > >
> > > > > If the bandwidth change notifications are important to somebody,
> > > > > please speak up, preferably with a patch that makes the notifications
> > > >
On 1/29/21 3:56 PM, Bjorn Helgaas wrote:
On Thu, Jan 28, 2021 at 06:07:36PM -0600, Alex G. wrote:
On 1/28/21 5:51 PM, Sinan Kaya wrote:
On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
AFAICT, this thread petered out with no resolution.
If the bandwidth change notifications are important to
Basic description of usage and effect for CFS Bandwidth Control Burst.
Signed-off-by: Huaixin Chang
Signed-off-by: Shanpei Chen
---
Documentation/scheduler/sched-bwc.rst | 70 +--
1 file changed, 66 insertions(+), 4 deletions(-)
diff --git a/Documentation
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 maximum amount of accumulated bandwidth is
bounded by "burst". And the maximun amount of CPU
Introduce statistics exports for the burstable cfs bandwidth
controller.
The following exports are included:
current_bw: current runtime in global pool
nr_burst: number of periods bandwidth burst occurs
burst_time: cumulative wall-time that any cpus has
used above quota in
Accumulate unused quota from previous periods, thus accumulated
bandwidth runtime can be used in the following periods. During
accumulation, take care of runtime overflow. Previous non-burstable
CFS bandwidth controller only assign quota to runtime, that saves a lot.
A sysctl parameter
1 - 100 of 1004 matches
Mail list logo
