| Message ID | 20220927213501.4069117-1-alex.bennee@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] tests/qtest: bump up QOS_PATH_MAX_ELEMENT_SIZE | expand |
What is an example of one such huge path? This would mean that LTO is changing the set of tests that are run, which is unexpected. Paolo Il mar 27 set 2022, 23:35 Alex Bennée <alex.bennee@linaro.org> ha scritto: > It seems the depth of path we need to support can vary depending on > the order of the init constructors getting called. It seems > --enable-lto shuffles things around just enough to push you over the > limit. > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186 > --- > tests/qtest/libqos/qgraph.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/qtest/libqos/qgraph.h b/tests/qtest/libqos/qgraph.h > index 6e94824d09..5c0046e989 100644 > --- a/tests/qtest/libqos/qgraph.h > +++ b/tests/qtest/libqos/qgraph.h > @@ -24,7 +24,7 @@ > #include "libqos-malloc.h" > > /* maximum path length */ > -#define QOS_PATH_MAX_ELEMENT_SIZE 50 > +#define QOS_PATH_MAX_ELEMENT_SIZE 64 > > typedef struct QOSGraphObject QOSGraphObject; > typedef struct QOSGraphNode QOSGraphNode; > -- > 2.34.1 > >
Paolo Bonzini <pbonzini@redhat.com> writes: > What is an example of one such huge path? This would mean that LTO is changing the set of tests that are run, which is > unexpected. It does look like the LTO build runs more tests although its hard to diff as the order if different: ➜ grep "list" without-lto | wc -l 201
Oh, wait, this is not a path! This is the stack for a graph visit, and the limit is not the maximum length of the path, but rather the number of nodes in the graph. In other words, QOS_PATH_MAX_ELEMENT_SIZE is being overloaded and using it in qos_node_stack is wrong. The solution is to use a linked list there, for now the patch is okay. Paolo Il mer 28 set 2022, 10:48 Alex Bennée <alex.bennee@linaro.org> ha scritto: > > Paolo Bonzini <pbonzini@redhat.com> writes: > > > What is an example of one such huge path? This would mean that LTO is > changing the set of tests that are run, which is > > unexpected. > > It does look like the LTO build runs more tests although its hard to > diff as the order if different: > > ➜ grep "list" without-lto | wc -l > 201 >
Il mar 27 set 2022, 23:35 Alex Bennée <alex.bennee@linaro.org> ha scritto: > It seems the depth of path we need to With s/path/stack/, Acked-by: Paolo Bonzini <pbonzini@redhat.com> Paolo support can vary depending on the order of the init constructors getting called. It seems > --enable-lto shuffles things around just enough to push you over the > limit. > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186 > --- > tests/qtest/libqos/qgraph.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/qtest/libqos/qgraph.h b/tests/qtest/libqos/qgraph.h > index 6e94824d09..5c0046e989 100644 > --- a/tests/qtest/libqos/qgraph.h > +++ b/tests/qtest/libqos/qgraph.h > @@ -24,7 +24,7 @@ > #include "libqos-malloc.h" > > /* maximum path length */ > -#define QOS_PATH_MAX_ELEMENT_SIZE 50 > +#define QOS_PATH_MAX_ELEMENT_SIZE 64 > > typedef struct QOSGraphObject QOSGraphObject; > typedef struct QOSGraphNode QOSGraphNode; > -- > 2.34.1 > >
On 27/09/2022 23.35, Alex Bennée wrote: > It seems the depth of path we need to support can vary depending on > the order of the init constructors getting called. It seems > --enable-lto shuffles things around just enough to push you over the > limit. > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186 > --- > tests/qtest/libqos/qgraph.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/qtest/libqos/qgraph.h b/tests/qtest/libqos/qgraph.h > index 6e94824d09..5c0046e989 100644 > --- a/tests/qtest/libqos/qgraph.h > +++ b/tests/qtest/libqos/qgraph.h > @@ -24,7 +24,7 @@ > #include "libqos-malloc.h" > > /* maximum path length */ > -#define QOS_PATH_MAX_ELEMENT_SIZE 50 > +#define QOS_PATH_MAX_ELEMENT_SIZE 64 > > typedef struct QOSGraphObject QOSGraphObject; > typedef struct QOSGraphNode QOSGraphNode; Acked-by: Thomas Huth <thuth@redhat.com>
diff --git a/tests/qtest/libqos/qgraph.h b/tests/qtest/libqos/qgraph.h index 6e94824d09..5c0046e989 100644 --- a/tests/qtest/libqos/qgraph.h +++ b/tests/qtest/libqos/qgraph.h @@ -24,7 +24,7 @@ #include "libqos-malloc.h" /* maximum path length */ -#define QOS_PATH_MAX_ELEMENT_SIZE 50 +#define QOS_PATH_MAX_ELEMENT_SIZE 64 typedef struct QOSGraphObject QOSGraphObject; typedef struct QOSGraphNode QOSGraphNode;
It seems the depth of path we need to support can vary depending on the order of the init constructors getting called. It seems --enable-lto shuffles things around just enough to push you over the limit. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186 --- tests/qtest/libqos/qgraph.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)