Linux-Development-Sys Digest #681, Volume #8 Mon, 30 Apr 01 13:13:14 EDT
Contents:
mmap memory allocated with vmalloc (Barry Smyth)
Software RAID-0 performance problem ... (William Gallafent)
Re: glibc 2.1.1 to 2.1.3 : Check ERROR (Olivier Gaquiere)
Re: Is linux kernel preemptive?? (Kasper Dupont)
Re: glibc 2.1.1 to 2.1.3 : Check ERROR (Andreas Jaeger)
symbols export/import (Doc)
Re: Evidence Eliminating .............10% OFF Instant Download
. 9676 (ChromeDome)
Re: Win Modems
Re: buffer cache ("Shirish")
----------------------------------------------------------------------------
From: Barry Smyth <[EMAIL PROTECTED]>
Subject: mmap memory allocated with vmalloc
Date: Mon, 30 Apr 2001 15:53:41 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
I am trying to map memory allocated in my driver to the user via mmap
functionality. I am using vmalloc to allocate this memory as my memory
requirements may exceed the 128K limit for kmalloc. Could someone please
tell me why the following code does not work.
unsigned long* kern_mem;
In open function:
kern_mem = (unsigned long*)vmalloc(PAGE_SIZE);
mem_map_reserve(MAP_NR((unsigned long)kern_mem));
In mmap function:
remap_page_range(vma->vm_start,
virt_to_phys((void*)kern_mem),
PAGE_SIZE,
vma->vm_page_prot);
In release function:
mem_map_unreserve(MAP_NR((unsigned long)kern_mem));
vfree((void*)kern_mem);
When accessing the memory from user space the memory seems to be filled
with -1 values, even after changing the values from within the driver.
When the memory allocation call is changed to kmalloc the code works
fine.
Thanks.
Barry
------------------------------
Date: Mon, 30 Apr 2001 16:01:43 +0100
From: William Gallafent <[EMAIL PROTECTED]>
Subject: Software RAID-0 performance problem ...
Hi,
This is reposted from Comp.OS.Linux.Misc since this appears to be a more
appropriate forum ...
My machine: Abit BP6 (dual Socket-370, BX chipset), 2 x Celeron 400 @
450 (75MHz fsb), 2 identical Maxtor 90650U2 HDDs (6.5GB, 2MB cache) one
as master on each of the Motherboard's PIIX IDE channels (not using the
HPT366 at present due to problems ages ago!), etc.
Short version of problem: RAID-0 striping at any chunk size is now
slower
(with 2.4 kernel) than the raw discs that make up the array!
Long version:
Running 2.4.0 kernel as per a fresh SuSE 7.1 installation. (I'll upgrade
to 2.4.latest as soon as I've worked this problem out and thus got a
decent disc configuration!)
Having acheived something close to optimal performance from the discs,
by experimentation, the configuration for each is the following:
root@linux:/home/williamg > hdparm -m4 -c1 -u1 -d1 -k1 -a4 -X66 -K1
/dev/hda
/dev/hda:
setting fs readahead to 4
setting 32-bit I/O support flag to 1
setting multcount to 4
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
setting keep_settings to 1 (on)
setting drive keep features to 1 (on)
setting xfermode to 66 (UltraDMA mode2)
multcount = 4 (on)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 1 (on)
readahead = 4 (on)
root@linux:/home/williamg > cat /proc/ide/piix
Intel PIIX4 Ultra 33 Chipset.
=============== Primary Channel ================ Secondary Channel
=============
enabled enabled
=============== drive0 ========= drive1 ======== drive0 ==========
drive1 ------
DMA enabled: yes no yes no
UDMA enabled: yes no yes yes
UDMA enabled: 2 X 2 2
UDMA
DMA
PIO
root@linux:/home/williamg > hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.44 seconds = 88.89 MB/sec
Timing buffered disk reads: 64 MB in 3.69 seconds = 17.34 MB/sec
All fine so far. I then create a RAID-0 device and perform the timings
again using hdparm on that (averages over a few test runs):
Chunk size (KB) :: approx. disk read speed (MB/s)
4 :: 12.6
8 :: 12.9
16 :: 13.1
32 :: 13.2
64 :: 7.9
128 :: 13.2
256 :: 13.5
512 :: 14.6
1024 :: 16.2
2048 :: 16.7
4096 :: 17.5
Rather strange, I think. Particularly since I used to get about 25MB/s
from the array using 128KB chunk size with the old mdtools and kernel
2.0 / 2.2 on the same interface (29MB/s on the HPT366 but with
filesystem corruption!).
Something to note is the following:
root@linux:/home/williamg > hdparm -Tt /dev/hda & hdparm -Tt /dev/hdc
[1] 994
/dev/hda:
/dev/hdc:
Timing buffer-cache reads: Timing buffer-cache reads: 128 MB in
2.60 seconds = 49.23 MB/sec
128 MB in 2.60 seconds = 49.23 MB/sec
Timing buffered disk reads: Timing buffered disk reads: 64 MB in
6.81 seconds = 9.40 MB/sec
root@linux:/home/williamg > 64 MB in 7.81 seconds = 8.19 MB/sec
Slightly jumbled, but the conclusion is that if I run hdparm on both
drives simultaneously, the transfer rate for each is halved ... even
though they're on different IDE channels.
So, what's the cause of the problem here? Is there something in the
kernel driver for the piix ide chipset that's killing performance when
accessing drives on different channels - or is it something with the new
raidtools, or is it something with my configuration?
All help welcome, and I'm happy to conduct experiments if this is
necessary ...
Thanks,
--
Bill Gallafent.
------------------------------
From: Olivier Gaquiere <[EMAIL PROTECTED]>
Subject: Re: glibc 2.1.1 to 2.1.3 : Check ERROR
Date: Mon, 30 Apr 2001 11:05:15 -0400
Thanks andreas,
I know 2.1.3 is not the latest but i've been heard that upgrading from 2.1.x
to another
2.1.x is more secure than upgrading to 2.2.x.
Is that true ??
I have another question before i try to install libc 2.1.3 over 2.1.1 :
In theory, the libc librairies are called libc-2.1.1.so, libm-2.1.1.so....
There are simlinks to these files, libc6.so to libc-2.1.1.so for example.
So with this sheme, it's "easy" to restore the old library after an failed
upgrade.
However, on my system, there is no link for libc in /lib
the file is called libc6.so and that's all.
So, when upgrading to another libc, i suppose libc6.so is replaced !!??
What is the way to save my current library and restore it if "make install"
fails ???
Besides, when i watch for the library files in the building directory, i
don't see
"libc-2.1.3.so" but "libc6.so" (i configured with "--prefix=/usr").
I configured with "--prefix=/usr/local/glibc-new" on another machine and
building
process had created "libc-2.1.3.so"
Why ??
Olivier
Andreas Jaeger a �crit :
> Olivier Gaquiere <[EMAIL PROTECTED]> writes:
>
> > Hello,
> >
> > I have to upgrade my libc 2.1.1 to 2.1.3 (jdk 1.3 needs this upgrade).
>
> 2.1.3 is quite old...
>
> > I work with Suse 6.2 and my system's components are :
> > Make 3.79
> > Gcc 2.95.2
> > Binutils 2.9.1.0.25
> > Bash 2.03
> >
> > Sources of glibc 2.1.3 are in /opt/progs/glibc-2.1.3 and i created a
>
> Can you write in that directory or is it read-only? If it's
> read-only, then you've encountered a bug in test-canon that has been
> fixed some time ago.
>
> > distinct directory
> > for building (/usr/local/glibc-build).
> >
> > I ran configure with LinuxThreads and Crypt Add-ons, and with
> > --prefix=/usr
> > Configure runs OK
> > Make runs OK
> >
> > My problem is :
> >
> > "Make check" exits with an error on
> > /usr/local/glibc-build/stdlib/test-canon
> > (i included the file "test-canon.out")
> >
> > I run "make check" again and the other tests seem to pass with success.
> > (i say "seem" because interpretation of some .out files is not obvious
> > and some
> > .out files are empty)
>
> We create out files for each test, empty .out files are ok. So it
> seems that only test-canon is broken. If you have a read-only source
> directory, then go ahead.
>
> Andreas
> --
> Andreas Jaeger
> SuSE Labs [EMAIL PROTECTED]
> private [EMAIL PROTECTED]
> http://www.suse.de/~aj
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Is linux kernel preemptive??
Date: Mon, 30 Apr 2001 15:20:15 +0000
Greg Copeland wrote:
>
> Kasper Dupont <[EMAIL PROTECTED]> writes:
>
> [snip]
> >
> > The problems you describe are related to locking
> > granularity not whether the system is preemptive.
> > When a process is preempted it is not preempted
> > by another process, but by an interrupt. Making
> > a system preemptive means you have to ensure two
> > things, first that interrupts are not disabled
> > for long periodes of time, and second that an
> > interrupt can actually result in a process
> > switch.
>
> Hmmm....seems like we are saying the same thing. Only you
> chose to be more detailed in the implementation details;
> which for this conversation I don't feel has significance which
> is why I left them out. When a kernel is preemptive (without
> regard for the triggering mechanism), it means that a system
> call can interrupt another system call; preempt the first
> system call prior to it completing. I'm not sure in
This is the point where you have misunderstood
something. A system call cannot preempt another
system call, no matter what the system looks like.
When some code is running it keeps running until
it gives up control or an interrupt arrives. If
code looses control because of an interrupt say
that it was preempted. This is triggered by an
interrupt, not a system call. It has to be this
way because as long as our code is running the
other system call is not running. If a system
call runs with interrupts enabled it can be
preempted otherwise it cannot, code that is not
prepared to be preempted must run with interrupts
disabled. If at some point another system call is
started before the first one has completed it
must be the case that the first one was preempted
by an interrupt otherwise the second wouldn't
even have had the chance to start.
Lots of system calls may sleep, that means
explicitly giving up control by calling the
scheduler. This is not called preemption, and is
really a hole different topic.
On SMP machines there can be multiple system
calls running at the same time even without
preemption. A process running on one CPU might
want to preempt a process running on another CPU,
it cannot do so directly, it has to be done
using an IPI (Inter Processor Interrupt).
> what you think that differs from why I described. Now then,
> I did proceed to talk about locks which have a direct
> bearing on the kernel's ability to be both, reentrant as
> well as preemptive. Not sure where I lost you there. Please
> remember that system call preemption is not user mode preemption.
> It's also important to remember that you can have a reentrant
> kernel without having reentrant system calls; that is, multiple
> asynchronous kernel entry points without allowing reentrancy in
> a common function. Example, A can preempt call B but A can not
> be preempted for another call A. This could be by design or
> by the required enforcement of lock for resource protection or
> even serialization. Long story short, it's hard to talk about
> preemption with talking about locking and reentrance. That,
> I *think*, is what I illustrated in my example that I snipped
> out (as it was long).
>
> >
> > Disabling interrupts when running kernel code is
> > not bad practice and is seldom a problem. When a
> > process spends long time within a sysytem call,
> > it is usually because the system call explecitly
> > sleeps. Thus we will have interrupts reenabled
> > in a short time anyway.
> >
>
> Again, not sure where I lost you. I'm pretty sure I
> didn't imply that disabling interrupts is a bad thing
> in general, however, it is for long periods of time.
> Again, I only addressed the distinction between coarse
> grain locks and fine grain locks and how it can effect
> the ability of a kernel to be reentrant.
>
> > So what we have to look for is not preemption,
> > because we already have that, but rather fine
> > grained locking. As I understand it 2.4.x is a
> > good step in that direction.
>
> Please describe how you have have system call preemption
> with coarse grain locks? In short, you can't because
> the kernel will be locking out anyone else from attempting
> to use the resource. It's hard to have one without the
> other which is not what I *think* you seem to be implying.
With the current design you cannot preempt a
kernel process holding locks, it would lead to
deadlocks. But that is really not that important,
user space code can be preempted and we really
don't need more preemption than that. The reason
we need fine grained locks is to better support
SMP architectures. On an SMP Linux system a
process will busy wait for spinlocks until the
process on another CPU holding the lock releases
it. If this happens too often we will waste lots
of CPU cycles.
On top of theese simple primitives more advanced
concurrency control can be build, there is also
some semaphore code in the kernel. This can be
used if you want to sleep while having a resource
locked. This is needed to avoid vasting CPU
cycles while waiting for an interrupt.
It seems that this is the kinds of locks you want
to discuss, but that has really nothing to do
with preemption, here we are discussing a much
higher abstraction layer.
>
> [snip - kernel locks explained removed]
>
> I just re-read my message and I guess I'm confused, because
> I'm not sure how you think you invalidated anything I said.
> I do have the impression that you have trouble with the
> concept of preemptive multitasking and preempting system
> calls. One does not require the other. I'm not trying to
> shoot back or anything, I'm just trying to understand the
> disconnect here.
>
> Thanks,
> Greg
>
> --
> Greg Copeland, Principal Consultant
> Copeland Computer Consulting
> --------------------------------------------------
> PGP/GPG Key at http://www.keyserver.net
> DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
> --------------------------------------------------
--
Kasper Dupont
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc 2.1.1 to 2.1.3 : Check ERROR
Date: 30 Apr 2001 17:29:58 +0200
Olivier Gaquiere <[EMAIL PROTECTED]> writes:
> Thanks andreas,
>
> I know 2.1.3 is not the latest but i've been heard that upgrading from 2.1.x
> to another
> 2.1.x is more secure than upgrading to 2.2.x.
> Is that true ??
No idea about that.
> I have another question before i try to install libc 2.1.3 over 2.1.1 :
>
> In theory, the libc librairies are called libc-2.1.1.so, libm-2.1.1.so....
> There are simlinks to these files, libc6.so to libc-2.1.1.so for example.
> So with this sheme, it's "easy" to restore the old library after an failed
> upgrade.
>
> However, on my system, there is no link for libc in /lib
> the file is called libc6.so and that's all.
> So, when upgrading to another libc, i suppose libc6.so is replaced !!??
Should be.
> What is the way to save my current library and restore it if "make install"
> fails ???
Build an RPM of libc (check how your distribution does it), install
the RPM - and if that fails use the old RPM.
> Besides, when i watch for the library files in the building directory, i
> don't see
> "libc-2.1.3.so" but "libc6.so" (i configured with "--prefix=/usr").
> I configured with "--prefix=/usr/local/glibc-new" on another machine and
> building
> process had created "libc-2.1.3.so"
> Why ??
What? You see libc.so.6 in your builddirectory, nothing else. The
other names are created during installation.
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
http://www.suse.de/~aj
------------------------------
From: Doc <[EMAIL PROTECTED]>
Subject: symbols export/import
Date: Mon, 30 Apr 2001 17:38:36 +0200
hi, i'm coding a module for kernel 2.4.
i've managed the way of exporting no symbols with the macro
EXPORT_NO_SYMBOLS.
now, as far as my module is inspired from another module (khttpd), some
functions have the same name of khttpd's ones but behave differently.
looking at /proc/modules i found this:
my_module 20877 1
khttpd 24272 3 [my_module]
how can i avoid this? i don't want to use khttpd's functions and such
dependence doesn't allow to rmmod khttpd before my_module.
bye
--
maruko.cjb.net - Seti@Home applets
Designed for Windows
Powered by Linux
------------------------------
From: ChromeDome <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.embedded,comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.m68k,comp.os.linux.misc
Subject: Re: Evidence Eliminating .............10% OFF Instant Download
. 9676
Date: Mon, 30 Apr 2001 16:17:26 GMT
[EMAIL PROTECTED] wrote:
>
> The World Famous Evidence Eliminator is set to double its price next
>month.....................Fact
> By now you will have read ALL the reports..
> We offer you 10% off at........... http://mission.sexhound.net/eliminator/
> Hurry and get Discount NOW! before the price increase..............
> Regards,
> Jerry, (Sales Mission Eliminator)
> ccpugjnsnuwydenxsylvpeshnsdetspsjffupghoxwsdpwvvodblfwcvvskr
For those who care to complain, the 800 number for the EE folks is:
1-866-500-6750
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To:
alt.computer.drivers,alt.os.linux,aus.computers.linux,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: Win Modems
Date: Sun, 29 Apr 2001 13:05:14 +0100
looking for a good, reliable modem that isnt winmodem based? try modems
based on rockwell chipsets. rockwell isnt rockwell anymore its conexant and
i think they brought in a few changes, none too bad i think. i had a
rockwell modem for years and it ran without problems at 56k, ermm.. until i
flashed it with the wrong firmware. but thats beyond the point, if youre
looking for an alternative, try looking for old rockwells or the new
conexants.
hope this helps,
the irish leprechaun
------------------------------
From: "Shirish" <[EMAIL PROTECTED]>
Subject: Re: buffer cache
Date: Mon, 30 Apr 2001 09:20:13 -0700
I think I am in the same problem. The way (and right now I think the only
one) is to do Raw I/O. This will bypass your buffer cache for disk I/O. I
haven't gotten any lead though for it. If you do, please let me know. The
O_DIRECT in the open() system call will be implemented in 2.5 which I dont
even know when 'to be release'
-s.
Zhiyong Xu <[EMAIL PROTECTED]> wrote in message
news:9cg3id$hd$[EMAIL PROTECTED]...
> Does all disk I/O go through buffer cache? All superblcok, inodes
and
> data block access must go thourgh buffer cache and can not pass it? So if
OS
> want to write some data to disk, it must copy to the corrsponding blocks
in
> buffer cache and mark it dirty, then at certain time, flush to disk?
> Is there any possibility disk I/O passby buffer cache?
>
> Thanks in advance.
>
>
>
>
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
