Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
On 2011-08-27 23:34, Nobuhiro Iwamatsu wrote: Hi, 2011/8/27 Jens Axboe ax...@kernel.dk: On 2011-08-26 15:00, Martin Steigerwald wrote: I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. As mentioned, the patch is already included. However, I would really appreciate if Iwamatsu-san would give it a compile and runtime test so that I know it's good. I don't have sh cross compilers on my system. And I'm pretty close to tagging the next release, would be a shame if 1.58 was released with broken sh support. I checked build and test. First, because fio was not able to build, I revised it. I attach a patch. And I tested with tiny config file. Work fine. I attached config file. Great, thanks for the fixup. It's applied now. -- Jens Axboe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Am Sonntag, 28. August 2011 schrieb Jens Axboe: On 2011-08-27 23:34, Nobuhiro Iwamatsu wrote: Hi, 2011/8/27 Jens Axboe ax...@kernel.dk: On 2011-08-26 15:00, Martin Steigerwald wrote: I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. As mentioned, the patch is already included. However, I would really appreciate if Iwamatsu-san would give it a compile and runtime test so that I know it's good. I don't have sh cross compilers on my system. And I'm pretty close to tagging the next release, would be a shame if 1.58 was released with broken sh support. I checked build and test. First, because fio was not able to build, I revised it. I attach a patch. And I tested with tiny config file. Work fine. I attached config file. Great, thanks for the fixup. It's applied now. Ok, so on uploading a new package with fio 1.58 I can have that bug closed via changelog entry then. Yay! Thanks for all the help, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
2011/8/28 Jens Axboe ax...@kernel.dk: On 2011-08-27 23:34, Nobuhiro Iwamatsu wrote: Hi, 2011/8/27 Jens Axboe ax...@kernel.dk: On 2011-08-26 15:00, Martin Steigerwald wrote: I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. As mentioned, the patch is already included. However, I would really appreciate if Iwamatsu-san would give it a compile and runtime test so that I know it's good. I don't have sh cross compilers on my system. And I'm pretty close to tagging the next release, would be a shame if 1.58 was released with broken sh support. I checked build and test. First, because fio was not able to build, I revised it. I attach a patch. And I tested with tiny config file. Work fine. I attached config file. Great, thanks for the fixup. It's applied now. Thnak you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
On 2011-08-26 15:00, Martin Steigerwald wrote: I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. As mentioned, the patch is already included. However, I would really appreciate if Iwamatsu-san would give it a compile and runtime test so that I know it's good. I don't have sh cross compilers on my system. And I'm pretty close to tagging the next release, would be a shame if 1.58 was released with broken sh support. -- Jens Axboe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hi,
2011/8/27 Jens Axboe ax...@kernel.dk:
On 2011-08-26 15:00, Martin Steigerwald wrote:
I can take it as patch in the debian package as well, Jens, if you prefer
not to include it upstream. But I guess you have no problem with including
it, since you have already done so. Please tell me if otherwise.
As mentioned, the patch is already included. However, I would really
appreciate if Iwamatsu-san would give it a compile and runtime test so
that I know it's good. I don't have sh cross compilers on my system. And
I'm pretty close to tagging the next release, would be a shame if 1.58
was released with broken sh support.
I checked build and test.
First, because fio was not able to build, I revised it.
I attach a patch.
And I tested with tiny config file.
Work fine. I attached config file.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
fio-test.fio
Description: Binary data
From 4d899cd0257b113c7e80f6ed2bd9ab69f59dc998 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu iwama...@nigauri.org
Date: Sun, 28 Aug 2011 06:34:37 +0900
Subject: [PATCH] Fix compile on environment of SuperH
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
---
arch/arch-sh.h |5 +
arch/arch.h| 14 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arch-sh.h b/arch/arch-sh.h
index ef4ee03..f5f313d 100644
--- a/arch/arch-sh.h
+++ b/arch/arch-sh.h
@@ -33,6 +33,11 @@
#define read_barrier() mb()
#define write_barrier() mb()
+#include stdio.h
+#include elf.h
+
+extern unsigned long arch_flags;
+
#define CPU_HAS_LLSC 0x0040
static inline int arch_init(char *envp[])
diff --git a/arch/arch.h b/arch/arch.h
index 16f4c3a..d598652 100644
--- a/arch/arch.h
+++ b/arch/arch.h
@@ -23,6 +23,13 @@ enum {
arch_generic,
};
+enum {
+ ARCH_FLAG_1 = 1 0,
+ ARCH_FLAG_2 = 1 1,
+ ARCH_FLAG_3 = 1 2,
+ ARCH_FLAG_4 = 1 3,
+};
+
#if defined(__i386__)
#include arch-x86.h
#elif defined(__x86_64__)
@@ -65,11 +72,4 @@ static inline int arch_init(char *envp[])
}
#endif
-enum {
- ARCH_FLAG_1 = 1 0,
- ARCH_FLAG_2 = 1 1,
- ARCH_FLAG_3 = 1 2,
- ARCH_FLAG_4 = 1 3,
-};
-
#endif
--
1.7.5.4
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
On 2011-08-26 00:16, Nobuhiro Iwamatsu wrote: Hi, 2011/8/25 Martin Steigerwald mar...@lichtvoll.de: Hi! I am putting upstream author Jens Axboe on CC. Thanks! Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstabl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? I thought that an overhead was bigger than the patch which you wrote as for my performing a check of synco every time when a program called memory barrier. Actually, the patch which you wrote is enough. Then everybody's happy, the patch is in and the packages can be updated :-) -- Jens Axboe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Am Freitag, 26. August 2011 schrieb Jens Axboe: On 2011-08-26 00:16, Nobuhiro Iwamatsu wrote: Hi, 2011/8/25 Martin Steigerwald mar...@lichtvoll.de: Hi! I am putting upstream author Jens Axboe on CC. Thanks! Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unst abl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? I thought that an overhead was bigger than the patch which you wrote as for my performing a check of synco every time when a program called memory barrier. Actually, the patch which you wrote is enough. Then everybody's happy, the patch is in and the packages can be updated :-) Okay, so I look into updating the package. Can take a while, I hope to come to it next week. I will then close this bug via changelog entry. Prior to having it uploaded I would like to have the patch compiled and tested. Nobuhiro can you do it on SuperH? If need be, I can update the debian git repo for fio first. Hopefully next week. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Am Freitag, 26. August 2011 schrieb Nobuhiro Iwamatsu: Hi, Hi! 2011/8/26 Jens Axboe ax...@kernel.dk: On 2011-08-25 18:47, Martin Steigerwald wrote: Am Donnerstag, 25. August 2011 schrieb Jens Axboe: On 2011-08-25 10:33, Martin Steigerwald wrote: [...] Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=un sta bl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? Ciao, How about something like the below, it's a bit more cleanly implemented? It still has the branch overhead per memory barrier, but I would not worry about that too much. Well sounds fine to me - not being into coding that much. If wanted I can include the patch into my debian package git repository for you SuperH folks to try out. Tell me, if you would like that. It's already in fio -git. Jens, what would be a good workload to test for any overhead issues? Small blocksizes? I do not find any references to memory barriers in fio´s documentation. Barriers are only used for verify workloads, and file locking. Both are expensive on the CPU side, so an extra branch for a barrier will be long in the noise. I would not worry about it. Looks good for me your patch. Thank you. However, I take this change to other CPU's and am effective? The patch which I sent is a change peculiar to Debian. It is originally an unnecessary change. It is nice that you take in this patch,; but for exclusive use of Debian if seem to be patched, should manage it in Debian. I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hi! I am putting upstream author Jens Axboe on CC. Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstabl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
On 2011-08-25 10:33, Martin Steigerwald wrote:
Hi!
I am putting upstream author Jens Axboe on CC.
Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu:
Hi,
[...]
2011/8/3 Martin Steigerwald m...@teamix.de:
Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens,
I am seeking information on the current status regarding
Please support sh4
http://bugs.debian.org/561891
and eventually help in resolving it if it has not already been
resolved.
When I am reading
http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstabl
e
correctly, then fio 1.50-1 has been build 167d before on buildd
kongou.
So is this issue resolved?
If not, please offer help. There is a partial patch mentioned earlier
in the bug report.
By this method, we cannot support both SH4 and SH4A. When we build
with machine of SH4A, a binary to work only in SH4A is built.
Because Debian SH team are supporting sh4 and sh4a in one binary, this
becomes the problem.
And this is a problem peculiar to Debian. It will not become the
problem in other distribution. (e.g., Gentoo)
It is necessary to check whether you do not do it whether we support
synco when we support both CPU's when we execute *_barrier.
I think that this has a big overhead.
I attached quick hack patch.
Jens, what do you think about such a patch? Please advice.
Nobuhiro, where do you think comes the big overhead from? In your patch
you check once at beginning for sinco capability. Do you refer to the if
statement you added in arch/arch-sh.h?
Ciao,
How about something like the below, it's a bit more cleanly implemented?
It still has the branch overhead per memory barrier, but I would not
worry about that too much.
diff --git a/arch/arch-sh.h b/arch/arch-sh.h
index 08c5fb3..ef4ee03 100644
--- a/arch/arch-sh.h
+++ b/arch/arch-sh.h
@@ -22,13 +22,38 @@
#define nop __asm__ __volatile__ (nop: : :memory)
-#if defined(__SH4A__)
-#definemb()__asm__ __volatile__ (synco: : :memory)
-#else
-#define mb() __asm__ __volatile__ ( : : : memory)
-#endif
+#define mb() \
+ do {\
+ if (arch_flags ARCH_FLAG_1) \
+ __asm__ __volatile__ (synco: : :memory);\
+ else\
+ __asm__ __volatile__ ( : : : memory); \
+ } while (0)
#define read_barrier() mb()
#define write_barrier()mb()
+#define CPU_HAS_LLSC 0x0040
+
+static inline int arch_init(char *envp[])
+{
+ Elf32_auxv_t *auxv;
+
+ while (*envp++ != NULL)
+ ;
+
+ for (auxv = (Elf32_auxv_t *) envp; auxv-a_type != AT_NULL; auxv++) {
+ if (auxv-a_type == AT_HWCAP) {
+ if (auxv-a_un.a_val CPU_HAS_LLSC) {
+ arch_flags |= ARCH_FLAG_1;
+ break;
+ }
+ }
+ }
+
+ return 0;
+}
+
+#define ARCH_HAVE_INIT
+
#endif
diff --git a/arch/arch.h b/arch/arch.h
index 8cafa11..16f4c3a 100644
--- a/arch/arch.h
+++ b/arch/arch.h
@@ -58,4 +58,18 @@ enum {
#include ../lib/ffz.h
#endif
+#ifndef ARCH_HAVE_INIT
+static inline int arch_init(char *envp[])
+{
+ return 0;
+}
+#endif
+
+enum {
+ ARCH_FLAG_1 = 1 0,
+ ARCH_FLAG_2 = 1 1,
+ ARCH_FLAG_3 = 1 2,
+ ARCH_FLAG_4 = 1 3,
+};
+
#endif
diff --git a/fio.c b/fio.c
index 7396421..9c1bed3 100644
--- a/fio.c
+++ b/fio.c
@@ -70,6 +70,8 @@ static pthread_t disk_util_thread;
static struct flist_head *cgroup_list;
static char *cgroup_mnt;
+unsigned long arch_flags = 0;
+
struct io_log *agg_io_log[2];
#define TERMINATE_ALL (-1)
@@ -1690,10 +1692,12 @@ static void run_threads(void)
fio_unpin_memory();
}
-int main(int argc, char *argv[])
+int main(int argc, char *argv[], char *envp[])
{
long ps;
+ arch_init(envp);
+
sinit();
init_rand(__fio_rand_state);
--
Jens Axboe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Am Donnerstag, 25. August 2011 schrieb Jens Axboe: On 2011-08-25 10:33, Martin Steigerwald wrote: Hi! I am putting upstream author Jens Axboe on CC. Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unsta bl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? Ciao, How about something like the below, it's a bit more cleanly implemented? It still has the branch overhead per memory barrier, but I would not worry about that too much. Well sounds fine to me - not being into coding that much. If wanted I can include the patch into my debian package git repository for you SuperH folks to try out. Tell me, if you would like that. Jens, what would be a good workload to test for any overhead issues? Small blocksizes? I do not find any references to memory barriers in fio´s documentation. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
On 2011-08-25 18:47, Martin Steigerwald wrote: Am Donnerstag, 25. August 2011 schrieb Jens Axboe: On 2011-08-25 10:33, Martin Steigerwald wrote: Hi! I am putting upstream author Jens Axboe on CC. Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: Hi, [...] 2011/8/3 Martin Steigerwald m...@teamix.de: Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unsta bl e correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. By this method, we cannot support both SH4 and SH4A. When we build with machine of SH4A, a binary to work only in SH4A is built. Because Debian SH team are supporting sh4 and sh4a in one binary, this becomes the problem. And this is a problem peculiar to Debian. It will not become the problem in other distribution. (e.g., Gentoo) It is necessary to check whether you do not do it whether we support synco when we support both CPU's when we execute *_barrier. I think that this has a big overhead. I attached quick hack patch. Jens, what do you think about such a patch? Please advice. Nobuhiro, where do you think comes the big overhead from? In your patch you check once at beginning for sinco capability. Do you refer to the if statement you added in arch/arch-sh.h? Ciao, How about something like the below, it's a bit more cleanly implemented? It still has the branch overhead per memory barrier, but I would not worry about that too much. Well sounds fine to me - not being into coding that much. If wanted I can include the patch into my debian package git repository for you SuperH folks to try out. Tell me, if you would like that. It's already in fio -git. Jens, what would be a good workload to test for any overhead issues? Small blocksizes? I do not find any references to memory barriers in fio´s documentation. Barriers are only used for verify workloads, and file locking. Both are expensive on the CPU side, so an extra branch for a barrier will be long in the noise. I would not worry about it. -- Jens Axboe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hi,
2011/8/25 Martin Steigerwald mar...@lichtvoll.de:
Hi!
I am putting upstream author Jens Axboe on CC.
Thanks!
Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu:
Hi,
[...]
2011/8/3 Martin Steigerwald m...@teamix.de:
Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens,
I am seeking information on the current status regarding
Please support sh4
http://bugs.debian.org/561891
and eventually help in resolving it if it has not already been
resolved.
When I am reading
http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstabl
e
correctly, then fio 1.50-1 has been build 167d before on buildd
kongou.
So is this issue resolved?
If not, please offer help. There is a partial patch mentioned earlier
in the bug report.
By this method, we cannot support both SH4 and SH4A. When we build
with machine of SH4A, a binary to work only in SH4A is built.
Because Debian SH team are supporting sh4 and sh4a in one binary, this
becomes the problem.
And this is a problem peculiar to Debian. It will not become the
problem in other distribution. (e.g., Gentoo)
It is necessary to check whether you do not do it whether we support
synco when we support both CPU's when we execute *_barrier.
I think that this has a big overhead.
I attached quick hack patch.
Jens, what do you think about such a patch? Please advice.
Nobuhiro, where do you think comes the big overhead from? In your patch
you check once at beginning for sinco capability. Do you refer to the if
statement you added in arch/arch-sh.h?
I thought that an overhead was bigger than the patch which you wrote as for
my performing a check of synco every time when a program called memory barrier.
Actually, the patch which you wrote is enough.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hi,
2011/8/26 Jens Axboe ax...@kernel.dk:
On 2011-08-25 18:47, Martin Steigerwald wrote:
Am Donnerstag, 25. August 2011 schrieb Jens Axboe:
On 2011-08-25 10:33, Martin Steigerwald wrote:
Hi!
I am putting upstream author Jens Axboe on CC.
Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu:
Hi,
[...]
2011/8/3 Martin Steigerwald m...@teamix.de:
Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens,
I am seeking information on the current status regarding
Please support sh4
http://bugs.debian.org/561891
and eventually help in resolving it if it has not already been
resolved.
When I am reading
http://buildd.debian-ports.org/status/package.php?p=fiosuite=unsta
bl e
correctly, then fio 1.50-1 has been build 167d before on buildd
kongou.
So is this issue resolved?
If not, please offer help. There is a partial patch mentioned
earlier in the bug report.
By this method, we cannot support both SH4 and SH4A. When we build
with machine of SH4A, a binary to work only in SH4A is built.
Because Debian SH team are supporting sh4 and sh4a in one binary,
this becomes the problem.
And this is a problem peculiar to Debian. It will not become the
problem in other distribution. (e.g., Gentoo)
It is necessary to check whether you do not do it whether we support
synco when we support both CPU's when we execute *_barrier.
I think that this has a big overhead.
I attached quick hack patch.
Jens, what do you think about such a patch? Please advice.
Nobuhiro, where do you think comes the big overhead from? In your
patch you check once at beginning for sinco capability. Do you refer
to the if statement you added in arch/arch-sh.h?
Ciao,
How about something like the below, it's a bit more cleanly
implemented? It still has the branch overhead per memory barrier, but
I would not worry about that too much.
Well sounds fine to me - not being into coding that much. If wanted I can
include the patch into my debian package git repository for you SuperH
folks to try out. Tell me, if you would like that.
It's already in fio -git.
Jens, what would be a good workload to test for any overhead issues? Small
blocksizes? I do not find any references to memory barriers in fio´s
documentation.
Barriers are only used for verify workloads, and file locking. Both are
expensive on the CPU side, so an extra branch for a barrier will be long
in the noise. I would not worry about it.
Looks good for me your patch. Thank you.
However, I take this change to other CPU's and am effective?
The patch which I sent is a change peculiar to Debian.
It is originally an unnecessary change.
It is nice that you take in this patch,; but for exclusive use of
Debian if seem to be patched, should manage it in Debian.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hi,
Sorry for reply.
2011/8/3 Martin Steigerwald m...@teamix.de:
Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens,
I am seeking information on the current status regarding
Please support sh4
http://bugs.debian.org/561891
and eventually help in resolving it if it has not already been resolved.
When I am reading
http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstable
correctly, then fio 1.50-1 has been build 167d before on buildd kongou.
So is this issue resolved?
If not, please offer help. There is a partial patch mentioned earlier in the
bug report.
By this method, we cannot support both SH4 and SH4A. When we build
with machine of SH4A, a binary to work only in SH4A is built.
Because Debian SH team are supporting sh4 and sh4a in one binary, this
becomes the problem.
And this is a problem peculiar to Debian. It will not become the
problem in other distribution. (e.g., Gentoo)
It is necessary to check whether you do not do it whether we support
synco when we support both CPU's when we execute *_barrier.
I think that this has a big overhead.
I attached quick hack patch.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
fio-1.57.debdiff
Description: Binary data
Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?
Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello Jens, I am seeking information on the current status regarding Please support sh4 http://bugs.debian.org/561891 and eventually help in resolving it if it has not already been resolved. When I am reading http://buildd.debian-ports.org/status/package.php?p=fiosuite=unstable correctly, then fio 1.50-1 has been build 167d before on buildd kongou. So is this issue resolved? If not, please offer help. There is a partial patch mentioned earlier in the bug report. Thanks, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 signature.asc Description: This is a digitally signed message part.
