duh! You argue over bandwidth due to sigs >4*80, and
other ppl here are QUOTING SIGS which is much worse,
and even the kcsf-ing LMKL footer.
And yep I have a .sig which I don't use on LKML due
to bandwidth.
Another point: look at the headers. I'd like LKML to
strip all these X-
I apologise if this is the wrong place for this, but i've been searching for
3 weeks for a way to record the bandwidth used by each user under 2.2.17, i
know there are ways to record bandwidth used by webpage hits but i also want
to monitor bandwidth used by any program the user has runnin
On 05.01 mirabilos wrote:
>
> Another point: look at the headers. I'd like LKML to
> strip all these X- thingies, the "Received:" etc.
> so that the messages I get have a bare minimum header
> consisting just of To: and Subject: (maybe MIME).
>
What you have todo is to learn how to configure y
On Tue, 1 May 2001, mirabilos wrote:
> Another point: look at the headers. I'd like LKML to
> strip all these X- thingies, the "Received:" etc.
> so that the messages I get have a bare minimum header
> consisting just of To: and Subject: (maybe MIME).
>
Er you wish to remove the abillity to tra
On Tue, May 01, 2001 at 05:53:12PM +0200, J . A . Magallon wrote:
> What you have todo is to learn how to configure your mailer to display
> headers you want. elm and balsa can do it. Do not know about Outlook...
> (btw, it is curious, mailing to lkml with outlook...)
Outlook express is different
> What you have todo is to learn how to configure your mailer to display
> headers you want.
Not the displaying annoys me, it's the traffic. The headers usually are
less than multiple quoted sigs, though.
> elm and balsa can do it. Do not know about
Outlook...
> (btw, it is cur
On Wed, May 02, 2001 at 09:35:05AM -, mirabilos wrote:
> > What you have todo is to learn how to configure your mailer to display
> > headers you want.
>
> Not the displaying annoys me, it's the traffic. The headers usually are
> less than multiple quoted sigs, though.
Headers serve a techn
On Sun, Oct 15, 2000 at 04:35:13AM -0500, Brian Parris wrote:
> I apologise if this is the wrong place for this, but i've been searching for
Well... the list is about kernel develoment, so it is a bit off-topic.
> 3 weeks for a way to record the bandwidth used by each user unde
I added an interface which is more intuitive
and takes less write/read systemcalls.
I think that most people don't really care period
and quota of CFS Bandwidth,
They just use it like
"I will allow this process to use 50% of single core" in most cases.
But I know that we sti
On Sun, Apr 28, 2019 at 04:32:06PM +0900, k-onishi wrote:
> I added an interface which is more intuitive
> and takes less write/read systemcalls.
>
> I think that most people don't really care period
> and quota of CFS Bandwidth,
>
> They just use it like
> "I
Le mardi 18 septembre 2007 à 06:29 -0500, Marco Peereboom a écrit :
> Now if they'd fix the copyright message to only mention Reyk all would
> be good.
All this mess so easily solved ? Too good to be true.
Xav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
That's it; that easy.
On Tue, Sep 18, 2007 at 02:04:46PM +0200, Xavier Bestel wrote:
> Le mardi 18 septembre 2007 ` 06:29 -0500, Marco Peereboom a icrit :
> > Now if they'd fix the copyright message to only mention Reyk all would
> > be good.
>
> All this mess so easily solved ? Too good to be tr
As per bandwidth table video driver is voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Fixes: 07f8f22a33a9e ("media: venus: core: remove CNOC voting while device
suspend")
Signed-off-by: Mansur Alisha Sh
As per bandwidth table video driver is voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Fixes: 7482a983d ("media: venus: redesign clocks and pm domains control")
Signed-off-by: Mansur Alisha Sh
As per bandwidth table we are voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Signed-off-by: Mansur Alisha Shaik
---
drivers/media/platform/qcom/venus/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
As per bandwidth table we are voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Signed-off-by: Mansur Alisha Shaik
---
drivers/media/platform/qcom/venus/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
As per bandwidth table we are voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Signed-off-by: Mansur Alisha Shaik
---
drivers/media/platform/qcom/venus/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
As per bandwidth table video driver is voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
Fixes: 7482a983d ("media: venus: redesign clocks and pm domains control")
Signed-off-by: Mansur Alisha Shaik
---
Ch
Allow to limit the network bandwidth for specific process containers (cgroups)
imposing additional delays in the sockets' sendmsg()/recvmsg() calls made by
those processes that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -one
[1.] One line summary of the problem:
Kernel 2.4.4 ac15
Tested with several cards and pieces of software, the outbound bandwidth
on a quad cpu alpha is 2 megabytes a second or less on a 100 mbit
switched ethernet network. Other machines on same switch do 10 or more
megabytes per second. Switch is
This is an experimental attempt to optimize my previous early flush
patch by adding continuous disk bandwidth estimation. In spirit, the
new modifications are similar to Stephen Tweedie's "sard" disk
monitoring patch, though it was only after implementing my own ideas
that I beca
bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happ
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
In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
NB = BWADJ[11:0] + 1
The recommended setting of NB: NB = NF / 2.
So:
NB = NF / 2
BWADJ[11:0] + 1 = NF / 2
BWADJ[11:0] = NF / 2 - 1
Right no
There's an accounting issue with the SCHED_DEADLINE and the creation of
cpusets. If a SCHED_DEADLINE task already exists and a new root domain
is created, the calculation of the bandwidth among the root domains
gets corrupted.
For the reproducer, I downloaded Juri's tests:
https://
From: Mansur Alisha Shaik
[ Upstream commit e44fb034b03231cd117d6db73fb8048deab6ea41 ]
As per bandwidth table video driver is voting with average bandwidth
for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
in bandwidth table.
suspend")
Fixes: 07f8f22a3
Quoting Mansur Alisha Shaik (2020-09-16 18:26:02)
> As per bandwidth table we are voting with average bandwidth
> for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
> in bandwidth table.
Why? It is in "the bandwidth table" but is there any reaso
Quoting Mansur Alisha Shaik (2020-09-23 23:51:05)
> As per bandwidth table video driver is voting with average bandwidth
> for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero
> in bandwidth table.
>
> Fixes: 7482a983d ("media: venus: redesign cloc
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for those processes
that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -oio-throttle io-throttle /dev/cgroup
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 10:09:28]:
> Allow to limit the network bandwidth for specific process containers (cgroups)
> imposing additional delays in the sockets' sendmsg()/recvmsg() calls made by
> those processes that exceed the limits defined
you use the full power
of the existing packet/connection matching available in the standard
iptables rules without having to add a new complex (but still limited)
API.
Paul
On Jan 23, 2008 1:09 AM, Andrea Righi <[EMAIL PROTECTED]> wrote:
> Allow to limit the network bandwidth for specific
Balbir Singh wrote:
> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 10:09:28]:
>
>> Allow to limit the network bandwidth for specific process containers
>> (cgroups)
>> imposing additional delays in the sockets' sendmsg()/recvmsg() calls made by
>> those
))
> schedule_timeout(sleep);
> ...
He's talking about cases where we want the behaviour to be
work-conserving, whilst still offering guarantees in the event of
contention. e.g. cgroups A and B each get a 20% guarantee on the TX
path if they need it, but anyone can use any
>> time_after(jiffies, last_time_exceeded + grace_time))
>> schedule_timeout(sleep);
>> ...
>
> He's talking about cases where we want the behaviour to be
> work-conserving, whilst still offering guarantees in the event of
> contention. e.g. cgroups A and B each
outbound bandwidth
> on a quad cpu alpha is 2 megabytes a second or less on a 100 mbit
> switched ethernet network. Other machines on same switch do 10 or more
> megabytes per second. Switch is DLink 3624, 24 port, only 12 ports in
> use.
>
> [2.] Full description of the problem/report:
On 25 May 2001 18:52:33 -0400, George France wrote:
> Hello Jay,
>
> I see that you are using the tulip driver. Could you try the de4x5 driver??
>
Its worse: reports 3.1 MBs and 1.6 MBs
--
--
Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc.
-
To unsubscribe from this list:
On Friday 25 May 2001 19:05, Jay Thorne wrote:
> On 25 May 2001 18:52:33 -0400, George France wrote:
> > Hello Jay,
> >
> > I see that you are using the tulip driver. Could you try the de4x5
> > driver??
>
> Its worse: reports 3.1 MBs and 1.6 MBs
wuftp is not exactly a performance benchmark, hav
On 25 May 2001 19:31:21 -0400, George France wrote:
> On Friday 25 May 2001 19:05, Jay Thorne wrote:
> > On 25 May 2001 18:52:33 -0400, George France wrote:
> > > Hello Jay,
> > >
> > > I see that you are using the tulip driver. Could you try the de4x5
> > > driver??
> >
> > Its worse: reports 3.
On Fri, May 25, 2001 at 05:25:03PM -0700, Jay Thorne wrote:
> But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough
> that anyone with an alpha running SMP can test it. Note that this
My smp alpha box drives a single tulip over 12MB/sec in full duplex
using tcp without any problem
On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote:
> [1.] One line summary of the problem:
> Kernel 2.4.4 ac15
> Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,
[ description of a slowdown skipped ].
Well, it looks that you have at least something to slo
Hello Andrea,
Jay, if the problem still exist in 2.4.5-pre6aa1 (please try the new kernel),
then I will have tech op's check this on Tuesday (Monday is a US holiday).
We should be able to duplicate this in the hardware lab and find the problem
with a logic analyser.
Best Regards,
--George
On 25 May 2001, Jay Thorne wrote:
> Netperf is a pretty good idea. Should not be a cpu bottleneck. Thats a
> good thing. So pretty much the same results as wu-ftpd: Note that I used
> the 466 mhz quad with a via-rhine, since the 400 locked up and was still
> fscking when I started this test.
>
>
Problem solved, thanks to the rawhide patch from Richard Henderson
([EMAIL PROTECTED]) posted on Sunday. Performance is ~10megs/second both
directions, using tulip, de4x5 or via-rhine.
Using 2.4.4-ac15 it works fine. I'm now trying 2.4.5
Andrea, 2.4.5aa1 oopses just after probing the scsi cards.
th any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_ban
From: Konstantin Khlebnikov
This is example of filesystem bandwidth controller build on the top of
dirty memory accounting, percpu_ratelimit and delay-injection.
Cgroup charges read/write requests into rate-limiters and injects delays
which controls overall speed.
Interface
Expose the bandwidth information as well via debugfs.
Signed-off-by: Viresh Kumar
Signed-off-by: Georgi Djakov
---
@Georgi: I am applying this along with your series.
drivers/interconnect/core.c | 18
drivers/opp/debugfs.c| 42
Here is a proposal to extend the OPP bindings with bandwidth based on
a previous discussion [1].
Every functional block on a SoC can contribute to the system power
efficiency by expressing its own bandwidth needs (to memory or other SoC
modules). This will allow the system to save power when high
Hi,
We are seeing hard lockup warnings caused by CFS bandwidth control code. The
test case below fails almost immediately on a reasonably large (144 thread)
POWER9 guest with:
watchdog: CPU 80 Hard LOCKUP
watchdog: CPU 80 TB:1134131922788, last heartbeat TB:1133207948315 (1804ms ago)
Modules
Hi Doug,
Am Dienstag, 21. Juli 2015, 13:41:23 schrieb Douglas Anderson:
> In the TRM we see that BWADJ is "a 12-bit bus that selects the values
> 1-4096 for the bandwidth divider (NB)":
> NB = BWADJ[11:0] + 1
> The recommended setting of NB: NB = NF / 2.
>
> So:
&g
On 07/21/2015 01:41 PM, Douglas Anderson wrote:
In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
NB = BWADJ[11:0] + 1
The recommended setting of NB: NB = NF / 2.
So:
NB = NF / 2
BWADJ[11:0] + 1 = NF / 2
BWADJ[11:0
Am Dienstag, 21. Juli 2015, 14:16:30 schrieb Stephen Boyd:
> On 07/21/2015 01:41 PM, Douglas Anderson wrote:
> > In the TRM we see that BWADJ is "a 12-bit bus that selects the values
> >
> > 1-4096 for the bandwidth divider (NB)":
> > NB = BWADJ[11:0] + 1
&
Stephen,
On Tue, Jul 21, 2015 at 2:16 PM, Stephen Boyd wrote:
> On 07/21/2015 01:41 PM, Douglas Anderson wrote:
>>
>> In the TRM we see that BWADJ is "a 12-bit bus that selects the values
>> 1-4096 for the bandwidth divider (NB)":
>> NB = BWADJ[11:0] + 1
On 07/21/2015 03:37 PM, Doug Anderson wrote:
Stephen,
On Tue, Jul 21, 2015 at 2:16 PM, Stephen Boyd wrote:
On 07/21/2015 01:41 PM, Douglas Anderson wrote:
In the TRM we see that BWADJ is "a 12-bit bus that selects the values
1-4096 for the bandwidth divider (NB)":
NB = BWADJ[11:
weight based blk-throttling can use the estimated bandwidth to calculate
cgroup bandwidth.
Signed-off-by: Shaohua Li
---
block/blk-core.c | 49 +
block/blk-sysfs.c | 13 +
include/linux/blkdev.h | 4
3 files changed
s.. :)
> > >
> > > On 03/02/16 13:55, Steven Rostedt wrote:
> >
> > [...]
> >
> > >
> > > Right. I think this is the same thing that happens after hotplug. IIRC
> > > the code paths are actually the same. The problem is that hotplu
: 996147
.dl_bw->total_bw : 209714
dl_rq[6]:
.dl_nr_running : 0
.dl_bw->bw : 996147
.dl_bw->total_bw : 209714
dl_rq[7]:
.dl_nr_running : 0
.dl_bw->bw : 996147
.dl_bw->tot
: 209714
> dl_rq[5]:
> .dl_nr_running : 0
> .dl_bw->bw : 996147
> .dl_bw->total_bw : 209714
> dl_rq[6]:
> .dl_nr_running : 0
> .dl_bw->bw : 996147
> .dl_bw->total_bw
On Wed, 3 Feb 2016 13:55:50 -0500
Steven Rostedt wrote:
> # grep dl /proc/sched_debug
> dl_rq[0]:
> .dl_nr_running : 0
> .dl_bw->bw : 996147
> .dl_bw->total_bw : -104857
> dl_rq[1]:
> .dl_nr_running : 0
> .dl_bw->bw
root domain
> is created, the calculation of the bandwidth among the root domains
> gets corrupted.
>
> For the reproducer, I downloaded Juri's tests:
>
> https://github.com/jlelli/tests.git
>
> For his burn.c file.
>
> https://github.com/jlelli/schedt
g. IIRC
> the code paths are actually the same. The problem is that hotplug or
> cpuset reconfiguration operations are destructive w.r.t. root_domains,
> so we lose bandwidth information when that happens. The problem is that
> we only store cumulative information regarding bandwidth
[...]
>
> >
> > Right. I think this is the same thing that happens after hotplug. IIRC
> > the code paths are actually the same. The problem is that hotplug or
> > cpuset reconfiguration operations are destructive w.r.t. root_domains,
> > so we lose bandwidth i
ct device
*parent,
return -EINVAL;
}
+ if (!bus->compute_params) {
+ dev_err(bus->dev,
+ "Bandwidth allocation not configured, compute_params no
set\n");
+ return -EINVAL;
+ }
+
mutex_init(&
g
linux-2.6.24-rc8-cgroup-io-throttling/init/Kconfig
--- linux-2.6.24-rc8/init/Kconfig 2008-01-16 05:22:48.0 +0100
+++ linux-2.6.24-rc8-cgroup-io-throttling/init/Kconfig 2008-01-18
16:14:09.0 +0100
@@ -313,6 +313,15 @@ config CGROUP_NS
for instance virtual servers
>Paul Menage wrote:
>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>>> Allow to limit the block I/O bandwidth for specific process containers
>>>> (cgroups)
On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> > Allow to limit the block I/O bandwidth for specific process containers
> > (cgroups) imposing additional delays on I/O requests for those proc
On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> Allow to limit the block I/O bandwidth for specific process containers
> (cgroups) imposing additional delays on I/O requests for those processes
> that exceed the limits defined in the control group filesystem.
>
Paul Menage wrote:
> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>> Allow to limit the block I/O bandwidth for specific process containers
>>> (cgroups) imposing additional
Naveen Gupta wrote:
>> Paul Menage wrote:
>>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>>>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>>>> Allow to limit the block I/O bandwidth for specific proces
Andrea Righi wrote:
> Naveen Gupta wrote:
>>> Paul Menage wrote:
>>>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>>>>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>>>>> Allow to
Andrea Righi wrote:
> >>>>>> Allow to limit the block I/O bandwidth for specific process
> >>>>>> containers
> >>>>>> (cgroups) imposing additional delays on I/O requests for those
> >>>>>> processes
> >&
* Jens Axboe <[EMAIL PROTECTED]> [2008-01-20 15:32:40]:
> On Sun, Jan 20 2008, Andrea Righi wrote:
> Your approach is totally flawed, imho. For instance, you don't want a
> process to be able to dirty memory at foo mb/sec but only actually
> write them out at bar mb/sec.
>
> The noop-iosched chan
lways be around. That's of course not the case.
Yes, this really need a lot of fixes. I simply posted the patch to know
if such approach (in general) could have sense or not.
> IOW, you are doing this at the wrong level.
>
> What problem are you trying to solve?
Limiting block I/O
correct, since the approach is
simply not feasible.
> > IOW, you are doing this at the wrong level.
> >
> > What problem are you trying to solve?
>
> Limiting block I/O bandwidth for tasks that belong to a generic cgroup,
> in order to provide a sort of a QoS on block I
need fixes, it needs to be redesigned :-). No amount of
> fixing will make the patch you posted correct, since the approach is
> simply not feasible.
>
>>> IOW, you are doing this at the wrong level.
>>>
>>> What problem are you trying to solve?
>> Lim
really need a lot of fixes. I simply posted the patch to know
> >> if such approach (in general) could have sense or not.
> >
> > It doesn't need fixes, it needs to be redesigned :-). No amount of
> > fixing will make the patch you posted correct, since the approac
Naveen Gupta wrote:
> See if using priority levels to have per level bandwidth limit can
> solve the priority inversion problem you were seeing earlier. I have a
> priority scheduling patch for anticipatory scheduler, if you want to
> try it. It's much simpler than CFQ priority.
On 22/01/2008, Andrea Righi <[EMAIL PROTECTED]> wrote:
> Naveen Gupta wrote:
> > See if using priority levels to have per level bandwidth limit can
> > solve the priority inversion problem you were seeing earlier. I have a
> > priority scheduling patch for anticipator
Naveen Gupta wrote:
> On 22/01/2008, Andrea Righi <[EMAIL PROTECTED]> wrote:
>> Naveen Gupta wrote:
>>> See if using priority levels to have per level bandwidth limit can
>>> solve the priority inversion problem you were seeing earlier. I have a
>>>
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
> Probably tracking who dirtied the pages would be the best approach, but
> we want also to reduce the overhead of this tracking. So, we should find
> a smart way to track which cgroup dirtied the pages and then only when
> the i/o schedule
Balbir Singh wrote:
> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>
>> Probably tracking who dirtied the pages would be the best approach, but
>> we want also to reduce the overhead of this tracking. So, we should find
>> a smart way to track which cgroup dirtied the pages and then o
Andrea Righi wrote:
> Balbir Singh wrote:
>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>>
>>> Probably tracking who dirtied the pages would be the best approach, but
>>> we want also to reduce the overhead of this tracking. So, we should find
>>> a smart way to track which cgroup di
Pavel Emelyanov wrote:
> Andrea Righi wrote:
>> Balbir Singh wrote:
>>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>>>
Probably tracking who dirtied the pages would be the best approach, but
we want also to reduce the overhead of this tracking. So, we should find
a sma
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-24 14:48:01]:
> Pavel Emelyanov wrote:
> > Andrea Righi wrote:
> >> Balbir Singh wrote:
> >>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
> >>>
> Probably tracking who dirtied the pages would be the best approach, but
> we want al
On Monday 28 May 2001 13:45, Jay Thorne wrote:
> Problem solved, thanks to the rawhide patch from Richard Henderson
> ([EMAIL PROTECTED]) posted on Sunday. Performance is ~10megs/second both
> directions, using tulip, de4x5 or via-rhine.
Well Done, Richard.
>
> Using 2.4.4-ac15 it works fine. I'
Hi,
Jeff spotted forgotten occurence of urb->bandwidth in isdn subsystem. When
fixing it, I have done quick grep over the tree and found another one
(which was even commented out). Let's just remove it.
[PATCH] USB SOUND: usbaudio - remove urb->bandwidth reference
Recent changes
rn, if we beat it to (re)enqueue the
> timer, it doesn't matter.
>
> Now, because hrtimers don't come with any serialization guarantees we
> must ensure both handler and (re)start loop serialize their access to
> the hrtimer to avoid both trying to forward the timer at the sa
On 3/13/19 2:30 PM, Georgi Djakov wrote:
Here is a proposal to extend the OPP bindings with bandwidth based on
a previous discussion [1].
Every functional block on a SoC can contribute to the system power
efficiency by expressing its own bandwidth needs (to memory or other SoC
modules). This
xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
to handle its own sw bandwidth managements and stores bandwidth data
into internal table every time add_endpoint() is called,
so when one endpoint's bandwidth allocation fails, all earlier
endpoints from same interface still r
Maximum allowed bandwidth has no dependency on the type
of panel used. Hence, cleanup the code to use max_bw_high
as the threshold value for bandwidth checks.
Update the maximum allowed bandwidth as 6.8Gbps for
SC7180 target.
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/disp/dpu1
Here is a proposal to extend the OPP bindings with bandwidth based on
a few previous discussions [1] and patchsets from me [2][3] and Saravana
[4][5][6][7][8][9].
Changes in v8:
* Addressed review comments from Matthias, Sibi and Viresh.
* Picked reviewed-by tags.
* Picked Sibi's interconnec
This patch adds the option for the user to select the filter bandwidth. The
user can also read the available bandwidths which are always adjusted to be
at most half of the sampling frequency. Furthermore, the currently selected
bandwidth can be read via the read_raw function, while the write_raw
This patch adds the option for the user to select the filter bandwidth. The
user can also read the available bandwidths which are always adjusted to be
at most half of the sampling frequency. Furthermore, the currently selected
bandwidth can be read via the read_raw function, while the write_raw
: Intel Memory bandwidth allocation
Update the 'intel_rdt_ui' documentation to have Memory bandwidth(b/w)
allocation interface usage.
Signed-off-by: Vikas Shivappa
Cc: ravi.v.shan...@intel.com
Cc: tony.l...@intel.com
Cc: fenghua...@intel.com
Cc: vikas.shiva...@intel.com
Link:
http://lkml.
Hi Johannes,
We've seen a handful of reports that seem to have verbose output from
the ieee80211_config_bw function in net/mac80211/mlme.c. It looks
similar to this:
[ 66.578652] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth, new config
is 2437 MHz, width 2 (2447/0 MHz)
[ 68.522437] w
Hi,
I am getting these messages from a Debian 9.3 system using
Linux 4.9.x:
[ 547.352746] usb 3-5.2: 3:1: usb_set_interface failed (-28)
[ 548.352865] usb 3-5.3: Not enough bandwidth for new device state.
[ 548.352868] usb 3-5.3: Not enough bandwidth for altsetting 1
I have connected a 7-Port
terrestrial delivery systems.
Possible values: ``1712000``, ``500``, ``600``, ``700``,
``800``, ``1000``.
+=== ===
+Terrestrial Standard Possible values for bandwidth
Hello.
I've faced an issue with a limited TCP bandwidth between my laptop and a
server in my 1 Gbps LAN while using BBR as a congestion control mechanism. To
verify my observations, I've set up 2 KVM VMs with the following parameters:
1) Linux v4.15.3
2) virtio NICs
3) 128 MiB o
Here is a proposal to extend the OPP bindings with bandwidth based on
a previous discussion [1].
Every functional block on a SoC can contribute to the system power
efficiency by expressing its own bandwidth needs (to memory or other SoC
modules). This will allow the system to save power when high
On Sat, Mar 16, 2019 at 12:32:49AM +0530, Sibi Sankar wrote:
>
>
> On 3/13/19 2:30 PM, Georgi Djakov wrote:
> > Here is a proposal to extend the OPP bindings with bandwidth based on
> > a previous discussion [1].
> >
> > Every functional block on a SoC c
Dne 09. 09. 20 v 8:26 Jaroslav Kysela napsal(a):
> Dne 08. 09. 20 v 15:15 Bard Liao napsal(a):
>> This algorithm computes bus parameters like clock frequency, frame
>> shape and port transport parameters based on active stream(s) running
>> on the bus.
>>
>> Developers can also implement their own
1 - 100 of 1278 matches
Mail list logo
