Age | Commit message (Collapse) | Author |
|
Using __DATE__ and __TIME__ will break reproducible builds. The
resulting binary will change with each rebuild even if the source and
toolchain is identical.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
is_reap_done() must also check that SIGINT or SIGTERM have come, or
we hang forever with such backtraces after Ctrl-C:
(gdb) thr a a bt
Thread 3 (Thread 0x7fbff8ff9700 (LWP 12607)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x0000000000402698 in replay_rec () at btreplay.c:1035
#2 0x00007fc001fe5454 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007fc001d1eecd in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fbfea7fc700 (LWP 12611)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x0000000000402698 in replay_rec () at btreplay.c:1035
#2 0x00007fc001fe5454 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007fc001d1eecd in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fc00282e700 (LWP 12597)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x0000000000402303 in __wait_cv () at btreplay.c:413
#2 0x0000000000401ae8 in main () at btreplay.c:426
Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: <linux-btrace@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
getpid() is a pid of a process, at least tid must be provided.
But if zero is passed, then calling thread will be used.
That exactly what is needed.
Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: <linux-btrace@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Size should be provided, not cpus number.
Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: <linux-btrace@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Currently, blktrace uses _SC_NPROCESSORS_CONF to find out the number of
CPUs. This is a problem, because if you reduce the number of online
CPUs by passing kernel parameter maxcpus, then blktrace fails to start
with the error:
FAILED to start thread on CPU 4: 22/Invalid argument
FAILED to start thread on CPU 5: 22/Invalid argument
...
The attached patch fixes it to use _SC_NPROCESSORS_ONLN.
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
In get_ncpus, we default to using 4096 CPUs if _SC_NPROCESSORS_CONF isn't
enabled. If that is insufficient, sched_getaffinity will fail and we
retry after doubling the size of the cpu_set_t allocation. There's a typo
in there that means we don't actually double the size and will loop
forever allocating the same sized cpu_set_t instead.
Signed-off-by: Josef Cejka <jcejka@suse.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Some distros have changed CPU_SETSIZE in glibc to 4096 since that matches
the NR_CPUS in the linux kernel config file. Some distros have decided to
leave CPU_SETSIZE at 1024. This is a problem if you want to run that distro
on a very large machine.
CPU_SETSIZE is use by the struct cpu_set_t. This means you to deal with cpus
greater the 1024 you must use the dynamic cpu sets, which involves converting
from things like CPU_SET to CPU_SET_S.
Cc: Jens Axboe <axboe@kernel.dk>
Modified by Jens to fix the CPU_{SET,ZERO}_S pointer mixup.
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
We should use the standard methods for getting the number of cpus in the
system when they are available. It is good practice to leave the old ways in
place for people stuck on older systems.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The current method fails if once we hit the first offlined cpu. This
will correct that case. However this still underreports the number cpus if
the last cpu are offlined.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
No point in malloc()ing space if we just immediately overwrite
the pointer via strdup. That'll leak some space.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
|
|
btreplay.c:1332: warning: comparison between signed and unsigned integer
expressions
|
|
Fixup for bz 502889.
Problem:
when executing with /dev/cciss/foo (long path names)
btreplay complains (No such file or directory).
Bug:
Missed back conversion of erscores to slashes.
Solution:
Convert underscores to slashes to restore device
names that have larger paths.
Signed-off-by: Edward Shishkin <edward@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Fedora linking changes picked this up:
/usr/bin/ld: btreplay.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
See also https://bugzilla.redhat.com/show_bug.cgi?id=564775
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
This is for RH bug 498426,
btrecord doesn't recognize --max-pkts and --max-packets cmd line options
Usage text and some documentation references "--max-pkts" and
the man page references "--max-packets" but the getopts code
is looking for --max_pkts.
I'm not sure if it's best to make the code match the majority
of the docs, or fix the docs to match the code? This patch does
the former, but I'm not picky if you want to go the other way :)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
|
|
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
This patch adds a new functionality to the btreplay tool, the -x option.
This parameter accelerate the replication by the factor specified. This
means that the stall time is divided by the number introduced.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
symbols
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
|
|
tip->vfp is only initialised when verbose > 1, so we must only use it
under the same circumstance.
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
|
|
Hopefully this will fix a gcc-4.2.1 warning.
Signed-off-by: Alan D. Brunelle <adb@korik.(none)>
|
|
These facilities allow one to attempt to replay a stream of IOs
captured with blktrace. The general workflow is:
1. Initiate blktrace to capture traces
2. Do whatever to generate initial IO stream...
3. Stop blktrace
4. Run btrecord to convert traces into IO records
5. Run btreplay to replay IOs
The IO stream characteristics during replay will try to respect the
following characteristics of the original IO stream:
1. The IOs will target the same device(s) as originally seen. [One can
alter this behavior by specifyin the -M option to btreplay, which
allows one to remap IOs slated to one set of devices to a specified
other set of devices.]
2. IO direction: the IOs will follow the same read/write
(from-device/to-device) characteristics of the originating flow. [Note:
By default replay will /not/ do writes, one must specify the -W option
to do this. THis is a meager attempt to stop someone from shooting
themselves in the foot (with a very large-caliber weapon).]
3. IO offset & size are maintained.
4. CPU: IOs are submitted on the originating CPU whenever possible. [Note:
Since we are using asynchronous IO, IOs may be routed to another CPU
prior to being processed by the block IO layer.]
In order to try and replicate inter-IO timing as much as possible,
btrecord will combine IOs "close in time" into one set, or bunch, of
IOs. Then btreplay will replay all the IOs in one go (via asynchronous
direct IO - io_submit). The size of the bunches are configurable via
the -m flag to btrecord (which specifies the a time-based bunch size)
and/or the -M flag (which specifies the maximum amount of IOs to put
into a bunch). At the low-end, specifying '-M 1' instructs btrecord to
act like fio - replay each IO as an individual unit.
Besides the potential to remap devices (utilizing the -M option to replay,
as noted above), one can also limit the number of CPUs on the replay
machine - so if you have fewer CPUs on the replay machine you specify
the -c option to btreplay.
Lastly, one can specify the -N option to btreplay to instruct it to ignore
inter-IO (inter-bunch of IOs) timings. Thus, this instructs btreplay
to replay the bunches as fast as possible, ignoring the original delays
between original IOs.
The utilities include a write-up in the docs directory.
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|