Linux-Development-Sys Digest #329, Volume #8 Thu, 7 Dec 00 11:13:16 EST
Contents:
Re: A faster memcpy and bzero for x86 ("Joshua Schaeffer")
Re: How to make a BIOS call in Linux (Paul Repacholi)
Re: this sucks! ("Willie Chan")
errors compiling kernel in checksum.S ([EMAIL PROTECTED])
Re: How to make a BIOS call in Linux (Tim Roberts)
Re: A faster memcpy and bzero for x86 (Tim Roberts)
Re: A faster memcpy and bzero for x86 ([EMAIL PROTECTED])
hogging transmitted sk_buff's ([EMAIL PROTECTED])
Re: kernel header problems ("O.Petzold")
Great reply; this guy needs a life ([EMAIL PROTECTED])
Time stamp counter - what's this ??? ("David Kalita")
Status of linuxthreads (Uma Nelluri)
Re: warning: cast from pointer (arnoud)
About software raid1 ("Kunda")
Re: c++ in kernel and linker problems (Mathias Waack)
ip-device driver interaction (Matthew Impett)
Re: How to make a BIOS call in Linux (Robert W. Curry)
Re: A faster memcpy and bzero for x86 (Johan Kullstam)
Re: A faster memcpy and bzero for x86 (Grant Edwards)
----------------------------------------------------------------------------
From: "Joshua Schaeffer" <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Date: Thu, 07 Dec 2000 03:51:49 GMT
> Now I'm just wondering why Linux doesn't already have these
> optimizations.
One reason might be that they are very unorthodox.
------------------------------
Subject: Re: How to make a BIOS call in Linux
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 06 Dec 2000 11:09:27 +0800
"Joshua Schaeffer" <[EMAIL PROTECTED]> writes:
> Why does the boot loader or APM even need to bother with BIOS in the first
> place?
Good question, and one I'd like to hear an answer to. As you have
to run LILO on a PC normally, why not include writing a real
boot block on the drive, and the secondary loaders etc.?
~Paul
------------------------------
From: "Willie Chan" <[EMAIL PROTECTED]>
Subject: Re: this sucks!
Date: Thu, 07 Dec 2000 04:41:11 GMT
i thought the UNIX is programmed by programmers for the "programmers"... and
now a programmer is complaining about an open source unix for "programmers"
<[EMAIL PROTECTED]> wrote in message
news:907oo8$ohn$[EMAIL PROTECTED]...
> Ok, I've asked two really simple questions soo far in this group, but
> haven't received one single answer. I'm new to linux drivers, and I
> really can't figure out exactly WHAT you all Linux geeks thinks is
> soooo good with linux!? I've written drivers for
> Win95/98/ME/CE/NT4/2000 and that is heaven compared with this shit!
>
> Open source - so what!? A good documentation can't be replaced by some
> nerdish source-code comments!
>
> Will you please do two things right for once?
> 1. Tell me how to open a tty device from a kernel model.
> 2. Buy a belt to those too-short and too-often weared jeans of yours.
>
> /E. D.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: errors compiling kernel in checksum.S
Date: Thu, 07 Dec 2000 05:42:16 GMT
Can someone help me? I am tring to compile a minimal linux 2.2.16 kernel
for a 386 and I ran into this error when running 'make zImage". I am
compiling on a RedHat 7, though I got the source from:
ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.16.tar.gz
Send helpful e-mail to [EMAIL PROTECTED]
THANK YOU!!!!!!!!!!!!!!!
gcc -D__KERNEL__ -I/home/lowdog/linux/include -D__ASSEMBLY__ -traditional -c
checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
Here are the two defines.
/*
* Copy from ds while checksumming, otherwise like csum_partial
*
* The macros SRC and DST specify the type of access for the instruction.
* thus we can call a custom exception handler for all access types.
*
* FIXME: could someone double-check whether I haven't mixed up some SRC and
* DST definitions? It's damn hard to trigger all cases. I hope I got
* them all but there's no guarantee.
*/
#define SRC(y...) \
9999: y; \
.section __ex_table, "a"; \
.long 9999b, 6001f ; \
.previous
#define DST(y...) \
9999: y; \
.section __ex_table, "a"; \
.long 9999b, 6002f ; \
.previous
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: How to make a BIOS call in Linux
Date: Wed, 06 Dec 2000 22:58:08 -0800
[EMAIL PROTECTED] wrote:
>I'm using a type of bios called smbios
>( http://www.phoenix.com/products/specs-smbios.pdf ) The spec is
>written by various PC and BIOS companies, eg, Intel and Phoenix tech.
>The smbios knows various aspects about the PC, including temperature,
>voltage, bios rev, bios build date, manufacturing, etc.
>
>The static info, e.g., bios rev, bios date, etc, I can get them by
>reading from a known location in memory. But for dynamic info,
>temperature, voltage, etc, it looks like I need to make the bios call.
>If there are other ways to get this info that would be great.
There is a package called "lrmi" (Linux Real-Mode Interface) which provides
a conveniently packaged wrapper around the built-in vm86 system call in
Linux. This lets you allocate and manage memory in the low megabyte,
including the ROM BIOS region, and lets you execute code in that region in
V86 mode. The S3 Savage code in the XFree86 3.3.6 server uses this package
to call the video BIOS for doing mode switches. It works surprisingly
well.
However, I've had a hard time finding lrmi recently. It was written by a
guy named Josh Vanderhoof. If you can't find it, let me know and I'll plop
a copy on my web site.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Date: Wed, 06 Dec 2000 23:05:35 -0800
Boris Gjenero <[EMAIL PROTECTED]> wrote:
>Today I tried to see if I can make a memcpy that's faster than the
>normal one. I quickly found out that if I just used processor
>instructions I couldn't improve things significantly. However, if I
>used the math coprocessor fildq / fsistpq (load/store 64 bit integer)
>instructions, that did improve performance.
Why do you use fildq/fsistpq, instead of just fld/fst? You can load any
arbitrary 8-byte value into a floating point register, as long as you don't
try to use it in a computation. Do you do an finit before you start?
>My best version takes 74% of the time taken by the normal memcpy when
>copying a million bytes. The loop does 64 bytes at a time; it consists
>of 8 fildq instructions which fill all 8 FPU registers, an addl to
>update a pointer, 8 fistpq instructions to store the data, and a jnz for
>looping.
It would be interesting to try interleaving your fildq's with mov's to see
if you can exploit parallelism between the integer unit and the floating
point unit.
>Now I'm just wondering why Linux doesn't already have these
>optimizations.
The kernel can't touch the floating point unit, so you're really talking
about the gnu C run-time library. This is just the kind of thing the gnu
compiler folks would eat up. Isn't there a place to submit suggestions?
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A faster memcpy and bzero for x86
Date: Thu, 07 Dec 2000 07:18:23 GMT
Boris Gjenero <[EMAIL PROTECTED]> wrote:
> I was doing this on a non-MMX Pentium system, but these tricks probably
> also apply to any CPU that's newer than the Pentium. They should all be
> able to benefit from 64 bit memory accesses and I doubt that Intel made
> the FPU any worse. Of course there's also MMX and 3D-Now. I don't know
> much about those, but I'm assuming they may allow even greater
> optimization.
Actually, the P4 FPU is slower than the P3, albeit it at much higher
clock speeds.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: hogging transmitted sk_buff's
Date: Thu, 07 Dec 2000 07:19:03 GMT
Hello,
I am developing a fast driver for GC82543: the new Gigabit Ethernet
MAC chip from Intel (I am writing "fast" not to brag, but to
differentiate from an available inefficient Intel driver).
Releasing of transmitted TX sk_buff's to stack is accomplished by
dev_kfree_skb(sk_buff *).
I can get a substantial performance improvement by not releasing TX
sk_buff's immediately, but later, when it is necessary, or even at
device close.
The problem is that the IP layer will stop giving me more sk_buff's
after I hold about 50 TCP sk_buff's, or even less than 8 UDP
sk_buff's. This is kernel 2.2.14 and 16. I don't want the things to
come to that.
My 2 questions are:
1. How big a sin is it to not release TX sk_buff's immediately (a sin
towards the stack and other comm drivers)?
2. If it is not a mortal sin, then where is it documented how many TX
sk_buff's I can hold before the IP stops giving me more, or is it
(reasonably) guaranteed to be a specific number, not to change in
future versions of Linux?
Thank you very much,
Mark Galecki
Senior Software Eng
SBS Tech
Newark, California
P.S. I will use this forum for a shameless job advert: if you know C,
are smart, responsible (no web surfers), and want to earn a very good
salary without working overtime, please contact me.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Re: kernel header problems
Date: Thu, 07 Dec 2000 09:20:56 +0100
Kaz Kylheku wrote:
> On Wed, 06 Dec 2000 09:57:50 +0100, O.Petzold <[EMAIL PROTECTED]> wrote:
> >>
> >
> >/usr/src/linux/include/linux/signal.h:159: warning: assignment of negative
> >value `-1' to `long unsigned int'
>
> There is nothing wrong with this assignment. To anyone with half a clue in
> C or C++ programming, it's a familiar idiom for the maximum value of the
> unsigned type. I find warnings like this to be extremely annoying.
Well, I know this technic but, getting a lot's of warnings is imo not a good idea
so this
is more to avoid confusing.
>
> >- case 1:
> >+ case 1: return;
>
> Or just a semicolon would do; the label needs to be followed by a statement.
> This switch statement is taking advantage of a gratuitous GNU C extension. I'm
> surprised that the same extension is not available in GNU C++.
>
> With -pedantic, gcc will catch this error in C code: ``warning: ANSI C forbids
> label at end of compound statement''. Maybe the kernel headers should
> first be cleaned up so that they pass -pedantic when compiled as C.
>
> >It's interesting to have the same errors with gcc and g++!
>
> That's because you are using the C++ compiler in both cases. The .cc suffix
> of your base source file determines that.
Yep, I forgot, the these are only the frontends.
Thanks Olaf
------------------------------
From: [EMAIL PROTECTED]
Subject: Great reply; this guy needs a life
Date: Thu, 07 Dec 2000 08:01:40 GMT
Amen, Julie. Great reply. This guy needs a life. I do both Linux and
Windblows development and do the best I can with the available tools
and documentation, without whining.
IMHO, if someone does not like something in life, they have 3 choices:
1. improve it
2. politely ask others to explain and/or improve
3. don't use it
With Windblows, choice "1" is not available, however.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David Kalita" <[EMAIL PROTECTED]>
Subject: Time stamp counter - what's this ???
Date: Wed, 06 Dec 2000 20:49:41 -0500
Hi
I have problem - I build a new kernel (2.4.0-test11) and now some
programs tell me that my procesor dosn't support TSC (time stamp
counter). But in the /proc/cpuinfo I have this feature ( Celeron ).
Maybe I forgot something to compile.
Could anyone tell me where I made mistake or point to any documentation.
Thanks
--
David Kalita
[EMAIL PROTECTED]
------------------------------
From: Uma Nelluri <[EMAIL PROTECTED]>
Subject: Status of linuxthreads
Date: Thu, 07 Dec 2000 14:40:09 +0530
Hi
I am trying to port a POSIX complaint multithreaded application to
Linux. Can anyone please let me know the status of Linux Threads. What
is the present version of Linix Threads? What is the status of
CLONE_PID? What is the status of Signal Handling?
Thanks,
Uma
------------------------------
From: arnoud <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.os.linux.alpha
Subject: Re: warning: cast from pointer
Date: Thu, 07 Dec 2000 10:59:06 +0100
For those cases that the warning is "just a warning" you should (MUST) do
the
cast your self e.g. if you have:
char cPrevCounter;
int iPnt;
cPrevCounter = (char)iPnt;
instead of
cPrevCounter = iPnt;
In this way you (or other reviewing your code) knows that you DID think
over that
there is the possiblity of cast problem.
If the warning isn't jus a warning you should fix the code for this!!!
Regards,
Arnoud.
"Dr. Unk" wrote:
> I would like know how to clean up a source, so that I do not get any
> more "warning: cast from pointer to integer of different size" or
> "incompatible pointer" warnings. I know that in most cases they are
> just that, warnings. But sometimes, I believe them to be the cause if
> many seg faults and floating point exceptions.
>
> My C knowledge is basic-level (2 courses taken). My system is an
> AlphaPC 164SX, Glibc-2.1.3, GCC-2.95.2, Linux-2.2.17.
>
> Thanks in advance.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Kunda" <[EMAIL PROTECTED]>
Subject: About software raid1
Date: Thu, 7 Dec 2000 20:09:18 +0800
Dear all,
I setup two ide disks and use linux software raid1.
How can I know if one ide disk fail, and how to detect it?
Please help me.
Thanks,
Kent
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: c++ in kernel and linker problems
Date: 07 Dec 2000 13:44:17 +0100
[EMAIL PROTECTED] writes:
> >>>>> "M.Waack" == O Petzold <[EMAIL PROTECTED]> writes:
Pls adjust your logic module.
> M.Waack> So the symbols are defined in the libstdc++. I agree with you
> M.Waack>staticaly linking is not a good idea.
And learn quoting, the sentence above wasn't written by me.
> try {
> char* p = new char[39];
> } catch(std::bad_alloc)
> { ...}
>
> M.Waack> and to use global flags for kernel space.
>
> This would require that you have the portion of the C++ runtime
> included in the kernel that manages exceptions. ... Which is Not The
> Case ...
And learn reading. Olaf wrote above this example:
"The other way could be in user space:"
Mathias
------------------------------
From: Matthew Impett <[EMAIL PROTECTED]>
Subject: ip-device driver interaction
Date: 7 Dec 2000 15:14:18 GMT
hey all, I have a question regarding the interaction between the ip layer
and the device drivers in linux. From what I have seen, through the
register_netdev call, the device driver registers a xmit function, which
ip then calls when it has a packet that needs to go out of that interface.
This is how it seems to work, with ip passing the packet directly to the
driver, possibly checking the dev->busy bit to see if the driver will accept
the packet, and possibly dropping it or trying again if the device is busy..
Now, my question regards this call to dev_init_buffers() and also the use of
dev->tx_queue_len. This makes it sound like there is a buffer right above
the device driver which ip can buffer the packet to. However, this seems to
go against what I see in the kernel, where IP sends directly to the driver..
If anyone can clarify exactly what is going on here that would be great..
Matt Impett
------------------------------
From: Robert W. Curry <[EMAIL PROTECTED]>
Subject: Re: How to make a BIOS call in Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 07 Dec 2000 10:27:55 -0500
lrmi is available on Source Forge these days.
http://sourceforge.net/projects/lrmi/
Bob
On Wed, 06 Dec 2000 22:58:08 -0800, Tim Roberts <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>
>>I'm using a type of bios called smbios
>>( http://www.phoenix.com/products/specs-smbios.pdf ) The spec is
>>written by various PC and BIOS companies, eg, Intel and Phoenix tech.
>>The smbios knows various aspects about the PC, including temperature,
>>voltage, bios rev, bios build date, manufacturing, etc.
>>
>>The static info, e.g., bios rev, bios date, etc, I can get them by
>>reading from a known location in memory. But for dynamic info,
>>temperature, voltage, etc, it looks like I need to make the bios call.
>>If there are other ways to get this info that would be great.
>
>There is a package called "lrmi" (Linux Real-Mode Interface) which provides
>a conveniently packaged wrapper around the built-in vm86 system call in
>Linux. This lets you allocate and manage memory in the low megabyte,
>including the ROM BIOS region, and lets you execute code in that region in
>V86 mode. The S3 Savage code in the XFree86 3.3.6 server uses this package
>to call the video BIOS for doing mode switches. It works surprisingly
>well.
>
>However, I've had a hard time finding lrmi recently. It was written by a
>guy named Josh Vanderhoof. If you can't find it, let me know and I'll plop
>a copy on my web site.
------------------------------
Subject: Re: A faster memcpy and bzero for x86
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 07 Dec 2000 10:00:26 -0500
Boris Gjenero <[EMAIL PROTECTED]> writes:
> Today I tried to see if I can make a memcpy that's faster than the
> normal one. I quickly found out that if I just used processor
> instructions I couldn't improve things significantly. However, if I
> used the math coprocessor fildq / fsistpq (load/store 64 bit integer)
> instructions, that did improve performance.
>
> My best version takes 74% of the time taken by the normal memcpy when
> copying a million bytes. The loop does 64 bytes at a time; it consists
> of 8 fildq instructions which fill all 8 FPU registers, an addl to
> update a pointer, 8 fistpq instructions to store the data, and a jnz for
> looping.
>
> Then I tried bzero, and I made a version that is twice as fast. My loop
> there isn't even unrolled; it does a single fstl per iteration. The
> nice thing with bzero is that a floating point zero is all bits zero so
> you can store a floating point number instead of an integer, and that's
> faster.
>
> I was doing this on a non-MMX Pentium system, but these tricks probably
> also apply to any CPU that's newer than the Pentium. They should all be
> able to benefit from 64 bit memory accesses and I doubt that Intel made
> the FPU any worse. Of course there's also MMX and 3D-Now. I don't know
> much about those, but I'm assuming they may allow even greater
> optimization.
>
> Now I'm just wondering why Linux doesn't already have these
> optimizations.
you can't just clobber the FPU regs, something else might be using
them. the kernel cannot use FPU without saving and restoring them
since they could be used in a userspace program (save/restore FPU every
time you enter the kernel is too expensive, FPU is only save/restore'd
at userspace program context switches). when you factor in the
overhead the FPU save/restore, using the FPU for memcpy suddenly
becomes less attractive. MMX also uses FPU registers so the same
thing goes for that too.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: A faster memcpy and bzero for x86
Date: Thu, 07 Dec 2000 15:45:03 GMT
In article <[EMAIL PROTECTED]>, Johan Kullstam wrote:
[regarding use of FPU to do memory move/fill]
>> Now I'm just wondering why Linux doesn't already have these
>> optimizations.
>
>you can't just clobber the FPU regs, something else might be using
>them. the kernel cannot use FPU without saving and restoring them
>since they could be used in a userspace program (save/restore FPU every
>time you enter the kernel is too expensive, FPU is only save/restore'd
>at userspace program context switches).
Are we talking about memcpy and bzero in glibc? In that case
it's not the kernel...
--
Grant Edwards grante Yow! ... Um...Um...
at
visi.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
