linux-kernel - [LTP] Better ways to generate Stress at Background

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1189509474.4568.46.camel@subratamodak.linux.ibm.com>
Date:	Tue, 11 Sep 2007 16:47:54 +0530
From:	Subrata Modak <subrata@...ux.vnet.ibm.com>
To:	ltp-list <ltp-list@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org
Subject: [LTP] Better ways to generate Stress at Background

Hi,

LTP has a fair program
(http://ltp.cvs.sourceforge.net/ltp/ltp/tools/genload/stress.c?revision=1.3&view=markup) which is capable of generating:
1) CPU stress,
2) Memory Stress,
3) Hard Disk Stress,
4) IO Bus Stress,
5) Network Stress (through netpipe)

in the Background, before your testcases (LTP) are run. The stress they
generate are wholesome and cannot be discrete. We need to device a
mechanism, where we can generate stress in matters of percentage (%),
say:
1) X% of CPU should be stressed during run,
2) Y% of Memory Stress,
3) Z% of Hard Disk Stress,
4) P% of IO Bus Stress,
5) Q% Network Stress (through netpipe)

And, all these should hold good on both Single CPU vs SMP machines as
well as to NUMA architecture. Can somebody provide some Idea on how to
design such a system ?
We may also face a situation like:
1) On an SMP machine with 8 CPUs, only 2 should be subjected to 60%
stress and others left normal, and lots of other combinations as well
2) On a NUMA machine, only particular node(s) should be stressed and
other left normal.

--Regards--
Subrata--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/