headers
Roman Zippel | 1 Feb 2003 01:01

Re: Perl in the toolchain

Hi,

On Sat, 1 Feb 2003, J.A. Magallon wrote:

> The easies way (from my point of view): write Perl::KConfig in C to do the logic
> hard work and build the big thing in perl. That will be putting a perl
> interface on top of klibc ?

You gain _nothing_ by rewritting it in perl. The backend is already a 
library and a swig interface file exists, so it's already trivial to 
generate Perl::KConfig. There is absolutely no reason to force people to 
use perl.

bye, Roman
Permalink | Reply | 1 comment |
headers
J.A. Magallon | 1 Feb 2003 01:05
Picon

Re: Perl in the toolchain


On 2003.02.01 Roman Zippel wrote:
> Hi,
> 
> On Sat, 1 Feb 2003, J.A. Magallon wrote:
> 
> > The easies way (from my point of view): write Perl::KConfig in C to do the logic
> > hard work and build the big thing in perl. That will be putting a perl
> > interface on top of klibc ?
> 
> You gain _nothing_ by rewritting it in perl. The backend is already a 
> library and a swig interface file exists, so it's already trivial to 
> generate Perl::KConfig. There is absolutely no reason to force people to 
> use perl.
> 

No, that was exactly what I tried to say, take nowadays C library, and build
a loadable module for perl (it has not to be written in perl). 

--

-- 
J.A. Magallon <jamagallon <at> able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre4-jam1 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk))
Permalink | Reply | 0 comments |
headers
Con Kolivas | 1 Feb 2003 01:12

Re: [BENCHMARK] ext3, reiser, jfs, xfs effect on contest


On Saturday 01 Feb 2003 12:20 am, Con Kolivas wrote:
> Using the osdl hardware (http://www.osdl.org) with contest
> (http://contest.kolivas.net) I've conducted a set of benchmarks with
> different filesystems. Note that contest does not claim to be a throughput
> benchmark.

Ok to complete the picture here is the set of results including dbench_load 
and ext2.

ctar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2559ext2        3       92      85.9    2       4.3     1.18
2559ext3        2       96      82.3    2       5.2     1.23
2559jfs         2       103     73.8    0       0.0     1.32
2559reiser      2       100     78.0    0       1.0     1.27
2559xfs         2       97      82.5    2       5.2     1.23
xtar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2559ext2        3       92      82.6    1       3.3     1.18
2559ext3        2       97      79.4    2       6.2     1.24
2559jfs         2       136     55.9    0       0.0     1.74
2559reiser      2       104     75.0    0       4.8     1.32
2559xfs         2       105     72.4    1       7.6     1.33
io_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2559ext2        3       105     71.4    5       6.6     1.35
2559ext3        3       109     68.8    4       10.1    1.40
2559jfs         3       138     54.3    11      13.8    1.77
2559reiser      3       98      76.5    2       9.2     1.24
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lang | 1 Feb 2003 01:19
Favicon

Re: [BENCHMARK] ext3, reiser, jfs, xfs effect on contest

I think it would be interesting to add ext2 in as well becouse a LOT of
people are still running ext2 and it would be nice to know how much
performance is being lost to gai the advantages of journaling.

David Lang

On Sat, 1 Feb 2003, Con Kolivas wrote:

> Date: Sat, 1 Feb 2003 09:21:59 +1100
> From: Con Kolivas <conman <at> kolivas.net>
> To: Hans Reiser <reiser <at> namesys.com>, Andrew Morton <akpm <at> digeo.com>
> Cc: linux-kernel <at> vger.kernel.org, Alexander Zarochentcev <zam <at> namesys.com>
> Subject: Re: [BENCHMARK] ext3, reiser, jfs, xfs effect on contest
>
> On Saturday 01 Feb 2003 6:29 am, Hans Reiser wrote:
> > Andrew Morton wrote:
> > >Hans Reiser <reiser <at> namesys.com> wrote:
> > >>compilation is not an effective benchmark anymore, not for Linux
> > >>filesystems, they are all just too fast (or is it that the compilers are
> > >>too slow?....)
> > >
> > >The point of this test is to measure interactions, and fairness.
> > >
> > >It answers the question "how much impact does heavy filesystem I/O have
> > > upon other system activity?".
> > >
> > >The "other system activity" in this test is a kernel compile.  That is a
> > >fairly reasonable metric, because it is sensitive to latencies in
> > > servicing reads and it is sensitive to inappropriate page replacement
> > > decisions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raghava Raju | 1 Feb 2003 01:23
Picon
Favicon

ethernet driver


Hi,

Kindly mail any links to some well known ethernet 
driver(intel pro) bugs and their fixes. Just wanted to
check against our source code >=2.4.2 , which may be
having some problems.

Please mail me at:vraghava_raju <at> yahoo.com as I did't 
subscribe.

Regards
Raghava

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 1 Feb 2003 01:29
Favicon

Re: Perl in the toolchain

Followup to:  <3E3B0557.3070400 <at> pobox.com>
By author:    Jeff Garzik <jgarzik <at> pobox.com>
In newsgroup: linux.dev.kernel
> 
> This is a logically correct argument, but also one that ignores basic 
> numbers.
> 
> The fact of the matter is, the area of build tools matters most to 
> people who cross-compile their kernels, because every tool is generally 
> hand-built rather than automatically installed on their Linux system. 
> For this audience, as well as the typical non-cross-compiling kernel 
> developer, Perl is on their system.
> 
> However, that fact is less significant than the more basic and core 
> argument:
> 
> klibc uses perl for text munging.  i.e. one of Perl's acknowledged 
> strengths.  This is not a case of choosing a favorite script language, 
> but instead a case of choosing "the right tool for the job."  Regardless 
> of whether you think Perl is line noise :) or not, from a technical 
> basis Perl is clearly superior to sed+awk in this case.
> 

Thanks Jeff :)

To emphasize things a bit further, Perl is:

a) good at munging text;
b) available on basically all development systems;
c) not host- or target-specific.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Piggin | 1 Feb 2003 01:37
Picon
Favicon

Re: [BENCHMARK] 2.5.59-mm7 with contest

Con Kolivas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Here are contest (http://contest.kolivas.net) benchmarks using the osdl 
>(http://www.osdl.org) hardware comparing mm7
>
>no_load:
>Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
>2.5.59          3       79      94.9    0       0.0     1.00
>2.5.59-mm6      1       78      96.2    0       0.0     1.00
>2.5.59-mm7      5       78      96.2    0       0.0     1.00
>cacherun:
>Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
>2.5.59          3       76      98.7    0       0.0     0.96
>2.5.59-mm6      1       76      97.4    0       0.0     0.97
>2.5.59-mm7      5       75      98.7    0       0.0     0.96
>process_load:
>Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
>2.5.59          3       92      81.5    28      16.3    1.16
>2.5.59-mm6      1       92      81.5    25      15.2    1.18
>2.5.59-mm7      4       90      82.2    25      18.3    1.15
>ctar_load:
>Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
>2.5.59          3       98      80.6    2       5.1     1.24
>2.5.59-mm6      3       112     70.5    2       4.5     1.44
>2.5.59-mm7      5       96      80.2    1       3.4     1.23
>xtar_load:
>Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roman Zippel | 1 Feb 2003 01:36

Re: kconfig (gconf) [PATCH]

Hi,

On Thu, 24 Jan 2002, Romain Lievin wrote:

> Well, I finished to write other views 2 weeks ago.
> gconf includes the same 3 views as qconf, uses your icons (sharing) and takes
> as much space as qconf.
> 
> Suggestions are welcome...
> 
> The patch is available on <http//tilp.info/perso>.

Thanks, the patch looks nice, so unless anyone has some serious 
objections, I'll include it into the next update.

bye, Roman
Permalink | Reply | 0 comments |
headers
Con Kolivas | 1 Feb 2003 01:44

Re: [BENCHMARK] 2.5.59-mm7 with contest

On Saturday 01 Feb 2003 11:37 am, Nick Piggin wrote:
> Con Kolivas wrote:
> >Seems the fix for "reads starves everything" works. Affected the tar loads
> >too?
>
> Yes, at the cost of throughput, however for now it is probably
> the best way to go. Hopefully anticipatory scheduling will provide
> as good or better kernel compile times and better throughput.
>
> Con, tell me, are "Loads" normalised to the time they run for?
> Is it possible to get a finer grain result for the load tests?

No, the load is the absolute number of times the load successfully completed. 
We battled with the code for a while to see if there were ways to get more 
accurate load numbers but if you write a 256Mb file you can only tell if it 
completes the write or not; not how much has been written when you stop the 
write. Same goes with read etc. The load rate is a more meaningful number but 
we haven't gotten around to implementing that in the result presentation.

Load rate would be:

loads / ( load_compile_time - no_load_compile_time )

because basically if the load compile time is longer, more loads are 
completed. Most of the time the loads happen at the same rate, but if the 
load rate was different it would be a more significant result than just a 
scheduling balance change which is why load rate would be a useful addition.

Con
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Germaschewski | 1 Feb 2003 01:48
Picon

Re: [PATCH] Module alias and device table support.

On Fri, 31 Jan 2003, Roman Zippel wrote:

> On Fri, 31 Jan 2003, Kai Germaschewski wrote:
> 
> > exactly great. In doing that, I already notice unresolved symbols and warn 
> > about them, which I think is an improvement to the build process, missing 
> > EXPORT_SYMBOL()s tend to go unnoticed quite often otherwise.
> 
> The problem here is that we use System.map, it's not that difficult to 
> extract the exported symbols:
> objcopy -j .kstrtab -O binary vmlinux .export.tmp
> tr \\0 \\n < .export.tmp > Export.map

What you say is right (except that it misses symbols exported from 
modules), but I don't see what you mean the problem is?

> It makes sense to keep depmod close to the linker, as both need the same 
> knowledge about resolving symbols, but I still don't know why that would 
> be a reason to put it into the kernel.

Well, I hope you mean into the kernel tree, it sure doesn't make sense to 
put it into the kernel itself.

Anyway, I think rusty's approach is to deal with the kernel-internal data 
structures from inside the kernel tree (during the build, that is) and 
generate data in a fixed format (.modalias) for depmod to read. Since 
depmod is external, it needs a fixed interface. Makes sense to me.

--Kai
(Continue reading)

Permalink | Reply | 3 comments |

Gmane