They're defined later on in the same file with bodies and
nothingin between needs them.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/coda_linux.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/coda_linux.h b/in
On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote:
>
> On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote:
>
> > They're defined later on in the same file with bodies and
> > nothingin between needs them.
> >
> > Signed-off-by: Ilpo Järvinen <[EM
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2 20
()
should be rethought but I don't have a clue how to do that.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 20 +---
net/core/skbuff.c | 21 +
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/in
-21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push
Again, current_text_addr() needs to addressed.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 18 +-
net/core/skbuff.c | 19 +++
2 files changed, 20 inse
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include
-28162 354 funcs, 3005 +, 31167 -, diff: -28162 --- skb_pull
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 15 +--
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/include
-10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 16 +---
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include
es removed, diff: -6593
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Cc: Vlad Yasevich <[EMAIL PROTECTED]>
---
include/net/sctp/sm.h |8 ++--
net/sctp/command.c| 12 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sm.h b
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
select for networking code might need a more fine-grained approach.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/infi
Codiff stats:
-16420 187 funcs, 103 +, 16523 -, diff: -16420 --- dst_release
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/dst.h | 10 +-
net/core/dst.c| 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/i
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2 20
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 20 2008 17:27, Patrick McHardy wrote:
> >> Striking. How can this even happen? A callsite which calls
> >>
> >> dev_alloc_skb(n)
> >>
> >> is just equivalent to
> >>
> >> __dev_alloc_skb(n, GFP_ATOMIC);
> >>
> >> which means there's like
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
> Ilpo Järvinen wrote:
> > I added inline to sctp_add_cmd and appropriate comment there to
> > avoid adding another call into the call chain. This works at least
> > with "gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)". Al
On Fri, 8 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 8 2008 22:34, ael wrote:
> >
> >Sure, I looked there in some depth. But some/most are special purpose or
> > 'locals'. One needs a map for the "main" repositories...
>
> Indeed, a page on kernelnewbies.org with the most important repositories
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:18 +0200 "Ilpo Järvinen" <[EMAIL PROTECTED]> wrote:
>
> > vmlinux.o:
> > 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
> >
> > ...+ these to lib/jh
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <[EMAIL PROTECTED]> wrote:
>
> > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
>
> This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain i
On Sat, 23 Feb 2008, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>
> >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
> >
> > This is a surprise. I expect that the -mm-only
> > profile-likely-unlikely-macros.patch is the cause of this and mainline
> > doesn't have t
On Wed, 5 Dec 2007, David Miller wrote:
> From: Reuben Farrelly <[EMAIL PROTECTED]>
> Date: Thu, 06 Dec 2007 17:59:37 +1100
>
> > On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > > - Lots of device IDs have been removed from the e1000 driver and moved
> > > over
> > > to e1000e. So if your e100
x27;t return it because it's on
the other list already). These manifest as fackets_out counting
error later on, the second-order effects are very hard to track,
so it may fix all out-standing TCP bug reports.
2) Prev == NULL check was wrong way around
3) Last skb's fack count was incorrectly
On Mon, 10 Dec 2007, Ilpo Järvinen wrote:
> Dave, please include this one to net-2.6.25.
...
> --
> [PATCH] [TCP]: Fix fack_count miscountings (multiple places)
I've better version of this coming up, so Dave please don't put this one
into net-2.6.25 (noticed that both t
On Thu, 13 Dec 2007, Cedric Le Goater wrote:
> I got this one while compiling on NFS.
>
> C.
>
> kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
I'm not exactly sure what patches you have applied and which patches are
not, with rc4-mm1 there are two patches (first one
On Mon, 21 Jan 2008, Dave Young wrote:
> Please see the kernel messages following,(trigged while using some qemu
> session)
> BTW, seems there's some e100 error message as well.
>
> PCI: Setting latency timer of device :00:1b.0 to 64
> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
>
On Tue, 22 Jan 2008, Dave Young wrote:
> On Jan 22, 2008 12:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 22, 2008 5:14 AM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, 21 Jan 2008, Dave Young wrote:
> > >
>
On Tue, 22 Jan 2008, David Miller wrote:
> From: "Dave Young" <[EMAIL PROTECTED]>
> Date: Wed, 23 Jan 2008 09:44:30 +0800
>
> > On Jan 22, 2008 6:47 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > > [PATCH] [TCP]: debug S+L
> >
>
On Wed, 23 Jan 2008, Dave Young wrote:
> On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 22 Jan 2008, David Miller wrote:
> >
> > > From: "Dave Young" <[EMAIL PROTECTED]>
> > > Date: Wed, 23 Jan 20
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
> On Wed, 23 Jan 2008, Dave Young wrote:
>
> > On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tue, 22 Jan 2008, David Miller wrote:
> > >
> > > > From: "Dav
its which won't be set with it at all.
Effectively, NewReno should always exists after the first
iteration anyway (or immediately if there's already head in
lost_out.
This was fixed earlier in net-2.6.25 but got reverted among other
stuff and I didn't notice that this is still ne
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
> And anyway, there were some fackets_out related
> problems reported as well and this doesn't help for that but I think I've
> lost track of who was seeing it due to large number of reports :-), could
> somebody refresh my memo
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
> got it !
>
> r3-06.test.meiosys.com login: WARNING: at
> /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> tcp_fastretrans_alert()
>
> Call Trace:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> I w
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it in
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
>
> > I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
On Wed, 3 Oct 2007, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > Try to capture the i/o log with the following command:
> > strace -o top.log top
>
> Thanks for the suggestion.
>
> > This will show for sure whether the kernel gives out incorrect data or
> > top misinterprets t
On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> On Wed, 3 Oct 2007, Frans Pop wrote:
>
> > The only change is in 2 consecutive columns: "2911 502" -> "2912 500".
> > Is processor usage calculated from those? Can someone explain how?
>
> The latte
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
> On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > The regression is:
> > 1)stoakley with 2 qual-core processors: 11%;
> > 2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
> I have new update on this issue and also cc to netdev maillist.
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
> On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
>
> > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > >
> > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > > regression is
On Fri, 14 Dec 2007, Ilpo Järvinen wrote:
> So, I might soon prepare a revert patch for most of the questionable
> TCP parts and ask Dave to apply it (and drop them fully during next
> rebase) unless I suddently figure something out soon which explains
> all/most of the problems,
On Wed, 19 Dec 2007, Eric Dumazet wrote:
> James Nichols a écrit :
> > On 12/19/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > > James Nichols a écrit :
> > > > > So you see outgoing SYN packets, but no SYN replies coming from the
> > > > > remote
> > > > > peer ? (you mention ACKS, but the firs
On Thu, 20 Dec 2007, James Nichols wrote:
> > I still dont understand.
> >
> > "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
> >
> > Without any exact data from you, I am afraid nobody can help.
>
> Oh, I didn't see that you specified specific options. I'll still have
> to ano
On Thu, 20 Dec 2007, James Nichols wrote:
> > You'd probably should also investigate the Linux kernel,
> > especially the size and locks of the components of the Sack data
> > structures and what happens to those data structures after Sack is
> > disabled (presumably the Sack data structure is in
On Sat, 4 Aug 2007, Ingo Molnar wrote:
> * Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > People just need to know about the performance differences - very few
> > realise its more than a fraction of a percent. I'm sure Gentoo will
> > use relatime the moment anyone knows its > 5% 8)
>
> noatime,no
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
> > (Nahant Update 5)]
> >
> > The problems start around time ind
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
> > On Sun, 29 Jul 2007, Willy Tarreau wrote:
> >
> > > On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > > > CLIENT = Linux 2.6.20.1
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote:
>
> > [...snip...]
> >
> > > BTW, some information are missing. It would have been better if the trace
> > > had been read with tcpdump -Svv. W
On Tue, 31 Jul 2007, Darryl L. Miles wrote:
> I've been able to capture a tcpdump from both ends during the problem and its
> my belief there is a bug in 2.6.20.1 (at the client side) in that it issues a
> SACK option for an old sequence which the current window being advertised is
> beyond it. T
I noticed that v2.6.23-rc1 locks up during boot, same thing happens now
with the latest linus' tree (+net-2.6.24 and tcp-2.6 tree stuff on top
of it; in -rc1 test they weren't though). The exact location of hang
varies a bit though. No OOPS, does not respond to sysrq or anything else
besides res
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sat, 11 Aug 2007 15:39:30 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
>
> > I noticed that v2.6.23-rc1 locks up during boot, same thing happens now
> > with the latest linus' tree (+net-2.6.2
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sun, 12 Aug 2007 14:20:46 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
> > On Sun, 12 Aug 2007, Andrew Morton wrote:
> > > On Sat, 11 Aug 2007 15:39:30 +0300 (EEST) "Ilpo Järvinen" <
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sun, 12 Aug 2007 20:15:51 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
>
> > Hmm, it was really worth of it, I did:
> > $ git-fetch linus
> > $ git-reset --hard linus
> > [...make &
...I guess those guys hunting for broken busyloops in the other thread
could also benefit from similar searching commands introduced in this
thread... ...Ccing Satyam to caught their attention too.
> On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote:
> >
> > There's more than a few
On Thu, 16 Aug 2007, Herbert Xu wrote:
> We've been through that already. If it's a busy-wait it
> should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
./drivers/telephony/ixj.c
6674:
A good candidate to checkpatch.pl's check list, btw.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/char/watchdog/wdt.c |3 ++-
drivers/char/watchdog/wdt_pci.c |3 ++-
drivers/scsi/osst.c |6 --
3 files changed, 8 insertions(+), 4 deletio
On Thu, 18 Oct 2007, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > > it's perfectly legitimate, in fact more robust. So if checkpatch.pl
> > > wants to make any noise about such constructs it should warn about
> > > the _lack_ of curly braces in every multi-line cond
On Wed, 24 Oct 2007, Adrian Bunk wrote:
> tcp_match_skb_to_sack() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
[...snip...]
Thanks, I should have noticed that right from the beginning...
Added DaveM to recipients.
--
i.
-
To unsubscribe from this list: send the lin
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> It's possible that new SACK blocks that should trigger new LOST
> markings arrive with new data (which previously made is_dupack
> false). In addition, I think this fixes a case where we get
> a cumulative ACK with enough SACK blocks to trigger the fast
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> On Sat, Oct 13, 2007 at 07:50:36PM +0200, Adrian Bunk wrote:
> > On Sat, Oct 13, 2007 at 07:22:14PM +0200, Willy Tarreau wrote:
> > >...
> > > Thanks for your help, I really appreciate it. In fact, I've reviewed them
> > > four, but two of them did not ap
On Thu, 8 Nov 2007, Rainer Jochem wrote:
> @@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
> *e++ = sizeof(ic_req_params);
> memcpy(e, ic_req_params, sizeof(ic_req_params));
> e += sizeof(ic_req_params);
> +
> + // Send it only if the ac
otentially a
negative packets in flight (= large one) disturbing cwnd compares.
[PATCH] [TCP]: Use S+L catcher only with SACK for now
TCP has a transitional state when SACK is not in use during
which this invariant is temporarily broken. Without SACK,
tcp_clean_rtx_queue does not decrement sac
On Thu, 29 Aug 2024, Ilpo Järvinen wrote:
> Building resctrl selftest fails on ARM because it uses __cpuid_count()
> that fails the build with error:
>
> CC resctrl_tests
> In file included from resctrl.h:24,
> from cat_test.c:11:
> In function '
reason for void casts in the stub
Ilpo Järvinen (4):
selftests/resctrl: Generalize non-contiguous CAT check
selftests/resctrl: Always initialize ecx to avoid build warnings
selftests/x86: don't clobber CFLAGS
kselftest: Provide __cpuid_count() stub on non-x86 archs
tools/testing
vendors.
Signed-off-by: Ilpo Järvinen
Reviewed-by: Muhammad Usama Anjum
---
tools/testing/selftests/resctrl/cat_test.c | 26 +-
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/resctrl/cat_test.c
b/tools/testing/selftests/resctrl
To avoid warnings when __cpuid_count() is an empty stub, always
initialize ecx because it is used in the return statement.
Signed-off-by: Ilpo Järvinen
Reviewed-by: Muhammad Usama Anjum
---
tools/testing/selftests/resctrl/cat_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
initialization before inclusion of lib.mk but leave adding
KHDR_INCLUDES into CFLAGS into the existing position because
KHDR_INCLUDES might be generated inside lib.mk.
Signed-off-by: Ilpo Järvinen
---
v4:
- New patch
tools/testing/selftests/x86/Makefile | 4 +++-
1 file changed, 3 insertions
uire it using uname -m.
Provide a stub for __cpuid_count() if HAVE_CPUID is not present to
allow build to succeed. The stub casts its arguments to void to avoid
causing "unused variable" or "set but not used" warnings.
Fixes: ae638551ab64 ("selftests/resctrl: Add non-contig
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
On Fri, 30 Aug 2024, Reinette Chatre wrote:
>
> Thank you for taking a look.
>
> On 8/30/24 3:56 AM, Ilpo Järvinen wrote:
> > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> >
>
> ...
>
> > > @@ -684,11 +622,13 @@ int resctrl_val(const struct resctrl
On Tue, 3 Sep 2024, Shuah Khan wrote:
> On 9/3/24 08:45, Ilpo Järvinen wrote:
> > This series first generalizes resctrl selftest non-contiguous CAT check
> > to not assume non-AMD vendor implies Intel. Second, it improves
> > selftests such that the use of __cpuid_count()
On Wed, 4 Sep 2024, Shuah Khan wrote:
> On 9/4/24 06:18, Ilpo Järvinen wrote:
> > On Tue, 3 Sep 2024, Shuah Khan wrote:
> >
> > > On 9/3/24 08:45, Ilpo Järvinen wrote:
> > > > This series first generalizes resctrl selftest non-contiguous CAT check
> >
On Tue, 3 Sep 2024, Reinette Chatre wrote:
> On 9/3/24 7:45 AM, Ilpo Järvinen wrote:
> > The x86 selftests makefile clobbers CFLAGS preventing lib.mk from
> > making the necessary adjustments into CFLAGS. This would lead to a
> > build failure after upcoming change which want
On Wed, 4 Sep 2024, Reinette Chatre wrote:
> 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:
> > > >
> > &
On Wed, 4 Sep 2024, Reinette Chatre wrote:
> On 9/4/24 4:57 AM, Ilpo Järvinen wrote:
> > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > On 8/30/24 3:56 AM, Ilpo Järvinen wrote:
> > > > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> > > > > @@ -69
On Thu, 5 Sep 2024, Reinette Chatre wrote:
> On 9/5/24 4:45 AM, Ilpo Järvinen wrote:
> > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > On 9/4/24 4:43 AM, Ilpo Järvinen wrote:
> > > > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > > > On 8/30/24
On Thu, 5 Sep 2024, Reinette Chatre wrote:
> On 9/5/24 5:10 AM, Ilpo Järvinen wrote:
> > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > On 9/4/24 4:57 AM, Ilpo Järvinen wrote:
> > > > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > > > On 8/30/24
ftest.h:74:9: error: impossible constraint in ‘asm’
>74 | __asm__ __volatile__ ("cpuid\n\t"
> \
> | ^~~
> cat_test.c:306:17: note: in expansion of macro ‘__cpuid_count’
> 306 | __cpuid_count(0x10, 2, eax, ebx, ecx, edx);
>
> Reported-by: Muhamma
On Fri, 6 Sep 2024, Reinette Chatre wrote:
> On 9/6/24 1:44 AM, Ilpo Järvinen wrote:
> > On Thu, 5 Sep 2024, Reinette Chatre wrote:
> > > On 9/5/24 4:45 AM, Ilpo Järvinen wrote:
> > > > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > > > On 9/4/24 4:4
On Fri, 6 Sep 2024, Reinette Chatre wrote:
> On 9/6/24 3:00 AM, Ilpo Järvinen wrote:
> > On Thu, 5 Sep 2024, Reinette Chatre wrote:
> > > On 9/5/24 5:10 AM, Ilpo Järvinen wrote:
> > > > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > > > On 9/4/24 4:5
the cur_state of the cooling device one-by-one
from max_state to what the cur_state was initially. The speed change
is confirmed by observing the current_link_speed for the corresponding
PCIe Port.
Signed-off-by: Ilpo Järvinen
---
MAINTAINERS | 1 +
tools
developed and should apply cleanly at least on top the
benchmark cleanup series (might apply cleanly also w/o the benchmark
series, I didn't test).
Ilpo Järvinen (5):
selftests/resctrl: Extend signal handler coverage to unmount on
receiving signal
selftests/resctrl: Remove duplicate fe
On Thu, 27 Sep 2007, Majumder, Rajib wrote:
> We have observed 40ms latency spikes in TCP connections in "burst" type of
> traffic.
> This affects regular TCP sockets.
Are segments being sent full-sized, or is there perhaps some Nagle
component in it as well? I.e., are the applications using TC
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> Hello !
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
>
> I just found that warning in my logs. It seems that it's been
> happening since rc7-mm1 at least.
>
> Thanks !
>
>
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>
> > I just found that warning in my logs. It seems that it's been
> > happening since rc7-mm1 at least.
> >
> > WARNING: at /home/legoater/linux/2.6.2
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
> Ilpo Järvinen wrote:
> > On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> >> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> >>
> >>> I just found that warning in my logs. It seems that it's
the cur_state of the cooling device one-by-one
from max_state to what the cur_state was initially. The speed change
is confirmed by observing the current_link_speed for the corresponding
PCIe Port.
Signed-off-by: Ilpo Järvinen
---
MAINTAINERS | 1 +
tools
On Thu, 12 Sep 2024, Reinette Chatre wrote:
> The benchmark used during the CMT, MBM, and MBA tests can be provided by
> the user via (-b) parameter, if not provided the default "fill_buf"
> benchmark is used. The user is additionally able to override
> any of the "fill_buf" default parameters whe
the cur_state of the cooling device one-by-one
from max_state to what the cur_state was initially. The speed change
is confirmed by observing the current_link_speed for the corresponding
PCIe Port.
Signed-off-by: Ilpo Järvinen
Reviewed-by: Jonathan Cameron
---
MAINTAINERS
On Thu, 17 Oct 2024, Reinette Chatre wrote:
> By default the MBM test uses the "fill_buf" benchmark to keep reading
> from a buffer with size DEFAULT_SPAN while measuring memory bandwidth.
> User space can provide an alternate benchmark or amend the size of
> the buffer "fill_buf" should use.
>
>
> index 250c320349a7..a53cd1cb6e0c 100644
> --- a/tools/testing/selftests/resctrl/resctrlfs.c
> +++ b/tools/testing/selftests/resctrl/resctrlfs.c
> @@ -182,7 +182,7 @@ int get_cache_size(int cpu_no, const char *cache_type,
> unsigned long *cache_size
>
> return -1;
> }
> - if (fscanf(fp, "%s", cache_str) <= 0) {
> + if (fscanf(fp, "%63s", cache_str) <= 0) {
> ksft_perror("Could not get cache_size");
> fclose(fp);
>
>
Reviewed-by: Ilpo Järvinen
--
i.
d operations.
>
> Keep the initialization of the, now unused, "fill_buf" parameters
> to reserve these parameter positions since it has been exposed as an API.
> Future parameter additions cannot use these parameter positions.
>
> Signed-off-by: Reinette Chatre
Reviewed-b
> Prevent user space from changing the "once" parameter and ensure
> that it is always false for the CMT, MBA, and MBM tests.
>
> Suggested-by: Ilpo Järvinen
> Signed-off-by: Reinette Chatre
Reviewed-by: Ilpo Järvinen
--
i.
> ---
> Changes since V2:
> -
On Thu, 17 Oct 2024, Reinette Chatre wrote:
> The benchmark used during the CMT, MBM, and MBA tests can be provided by
> the user via (-b) parameter, if not provided the default "fill_buf"
> benchmark is used. The user is additionally able to override
> any of the "fill_buf" default parameters whe
gt; Use the measured cache size to determine a buffer size that can be
> expected to trigger memory access while keeping the existing default
> as minimum, now renamed to MINIMUM_SPAN, that has been appropriate for
> testing so far.
>
> Signed-off-by: Reinette Chatre
Look good, th
s to be reconsidered if any of the test parameters are changed.
>
> Replace the magic constant as array size with the test parameters the
> array size depends on.
>
> Reported-by: Ilpo Järvinen
> Closes:
> https://lore.kernel.org/all/45af2a8c-517d-8f0d-137d-ad0f3f6a3...@lin
mark).
>
> Keep the "wait one second" delay before measurements start. For the
> default "fill_buf" benchmark this time now covers only the "runtime"
> portion that needs to be measured. For the user provided benchmark this
> delay maintains current
; fill_buf.memflush = 1;
> param.fill_buf = &fill_buf;
> }
>
It has a bit of code duplication feel in it so I'd consider adding
something like ssize_t get_default_span() (perhaps there exists a better
name for it that is not "span" based). Also DEFAULT_SPAN is no longer
truly the default span.
But neither is the end of the world as is...
Reviewed-by: Ilpo Järvinen
--
i.
atures or memory performance features that generate memory traffic
> + * may drive accesses that are counted differently by performance counters
> + * and MBM respectively, for instance generating "overhead" traffic which
> + * is not counted against any specific RMID.
> + */
> +#define THROTTLE_THRESHOLD 750
> +
> /*
> * fill_buf_param: "fill_buf" benchmark parameters
> * @buf_size:Size (in bytes) of buffer used in benchmark.
>
Reviewed-by: Ilpo Järvinen
--
i.
esc += bw_resc[runs];
> }
>
> - avg_bw_imc = sum_bw_imc / 4;
> - avg_bw_resc = sum_bw_resc / 4;
> + avg_bw_imc = sum_bw_imc / NUM_OF_RUNS;
> + avg_bw_resc = sum_bw_resc / NUM_OF_RUNS;
> avg_diff = (float)labs(avg_bw_resc - avg_bw_imc) / avg_bw_imc;
> avg_diff_per = (int)(avg_diff * 100);
While the patch itself is fine, I notice the code has this magic number
gem too:
unsigned long bw_imc[1024], bw_resc[1024];
Reviewed-by: Ilpo Järvinen
--
i.
e even if the user provides another value via command line.
> This behavior is maintained since the test requires that the buffer size
> matches the size of the cache allocated, and the amount of cache
> allocated can instead be changed by the user with the "-n" command line
&g
nchmark and omit the buffer size information if another benchmark
> is used.
>
> Fixes: ecdbb911f22d ("selftests/resctrl: Add MBM test")
> Signed-off-by: Reinette Chatre
Reviewed-by: Ilpo Järvinen
--
i.
> ---
> Backporting is not recommended. Backporting this fix will be
On Thu, 24 Oct 2024, Reinette Chatre wrote:
> Hi Shuah,
>
> On 10/24/24 3:36 PM, Shuah Khan wrote:
> >
> > Is this patch series ready to be applied?
> >
>
> I believe it is close ... I would like to give Ilpo some time to peek
> at patches 2 and 10 to confirm if I got their fixes right this ti
> Prevent user space from changing the "once" parameter and ensure
> that it is always false for the CMT, MBA, and MBM tests.
>
> Suggested-by: Ilpo Järvinen
> Signed-off-by: Reinette Chatre
> ---
> Changes since V1:
> - New patch
> ---
> tools/testin
1 - 100 of 104 matches
Mail list logo
