Displaying 12 results from an estimated 12 matches for "lloops".
Did you mean:
loops
2012 Nov 05
2
[LLVMdev] New benchmark in test-suite
Hi Daniel,
I'm trying to add LivermoreLoops test to the benchmark suite (tar ball
attached), but I'm getting the error below:
--- Tested: 2 tests --
FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.compile_time (1 of 2)
FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.execution_time (2 of 2)
When I use the option to only run this test:
--only-test SingleSource/Benchmarks/LivermoreLoops
I can see the binary and if I execute, it runs (still missing bits and
bobs, but ignore that for now)....
2012 Nov 06
0
[LLVMdev] New benchmark in test-suite
...:51 PM, Renato Golin <rengolin at systemcall.org>wrote:
> Hi Daniel,
>
> I'm trying to add LivermoreLoops test to the benchmark suite (tar ball
> attached), but I'm getting the error below:
>
> --- Tested: 2 tests --
> FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.compile_time (1 of 2)
> FAIL: SingleSource/Benchmarks/LivermoreLoops/lloops.execution_time (2 of 2)
>
> When I use the option to only run this test:
>
> --only-test SingleSource/Benchmarks/LivermoreLoops
>
> I can see the binary and if I execute, it runs (still missing bits and...
2008 Mar 25
2
patchless kernel
Dear All,
make[5]: Entering directory `/usr/src/kernels/2.6.23.15-80.fc7-x86_64''
/usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:142: warning:
''request_queue_t'' is deprecated
/usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:273: warning:
''request_queue_t'' is deprecated
/usr/src/redhat/BUILD/lustre-1.6.4.3/lustre/llite/lloop.c:312:
2012 Nov 07
1
[LLVMdev] New benchmark in test-suite
...the failure on compile_time indicates that the test isn't
> even building. As provided, the tests don't actually define the cpuida() or
> calculateMHz() functions so that seems expected to me.
I defined both functions as NOPs.
I got what it was. The original makefile had a "-o lloops" on the
compile command and I wrongfully copied it to the LDFLAGS, so it was
generating the binary on the current dir, not on the Output dir, where
it should belong. :)
> The compile failures end up getting buried in the logs, but they will either
> be in the test.log file in the top-l...
2016 Jun 30
17
[PATCH v2 00/12] gendisk: Generate uevent after attribute available
The race condition is noticed between disk_add() and disk attributes, on
virtio-blk hotplug.
Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that
point we haven't created the serial attribute file, therefore depending
on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get
created.
As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk
2016 Jun 30
17
[PATCH v2 00/12] gendisk: Generate uevent after attribute available
The race condition is noticed between disk_add() and disk attributes, on
virtio-blk hotplug.
Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that
point we haven't created the serial attribute file, therefore depending
on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get
created.
As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk
2013 Oct 29
0
[PATCH 07/23] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert
2013 Oct 29
0
[PATCH 07/23] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert
2013 Oct 29
0
[PATCH 07/23] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
Cc: Jens Axboe <axboe at kernel.dk>
Cc: Geert