Linux-Development-Sys Digest #740, Volume #8     Tue, 22 May 01 13:13:17 EDT

Contents:
  Re: How to find system and user memory used? ("Cameron Kerr")
  Re: Loading modules permanently (Rolf Magnus)
  How i sleep a thread, and doesn't block another thread? ("killerlife")
  Re: mmap() and msync() extensions? (Kasper Dupont)
  Re: Sharing the virtual address space? (Kasper Dupont)
  Re: Spambot Fodder - Dont Bother To Read - Thanks (SammyTheSnake)
  Re: unresolved symbol: open_namei (Kasper Dupont)
  Re: Time to read the Disk (Kasper Dupont)
  Re: Newbie programmer (Kasper Dupont)
  Re: make modules does not work (Kasper Dupont)
  Win NT boot and Lilo boot ("Hugin")
  Re: Trouble using large amount of memory with Redhat 7 ("Karl Heyes")
  looking for simple sleep func. in kernel (NortonNg)
  Re: How i sleep a thread, and doesn't block another thread? ("Nils O. Selåsdal")
  Too many open files (Arne Driescher)
  Write a module (Julien Laganier)
  Write a module (Julien Laganier)
  Crypto API/filesystems (Jonathan Buzzard)

----------------------------------------------------------------------------

From: "Cameron Kerr" <[EMAIL PROTECTED]>
Subject: Re: How to find system and user memory used?
Date: Tue, 22 May 2001 18:27:22 +1200

In article <9ectcp$28vma$[EMAIL PROTECTED]>, "Kyle Brant"
<[EMAIL PROTECTED]> wrote:

> Take a look at the sysinfo system call if you are writing a program.
> Gtop or ktop for programs that report such info (I think).

The program "free" will tell you this. I suggest you use this to look for
examples, as there will be way less code to wade through.

-- 
Cameron Kerr -- cameron.kerr @ paradise.net.nz
Praise Slackware, our baud and saviour!
--

------------------------------

From: Rolf Magnus <[EMAIL PROTECTED]>
Subject: Re: Loading modules permanently
Date: Tue, 22 May 2001 09:44:48 +0200

Heinz Ruffieux wrote:

> Thanks a lot for your support. In your statement I read, that there is NO
> other way to load modules that adding the modprobe <module> command in
> /etc/modules.conf - right? I thougt, that there is an other way. This was
> confusing me.

Not in modules.conf, but in rc.local
If "automated" in your sense means not to write 'modprobe blah' into a 
script to load a module, but just 'blah' into another file, you can add 
this to rc.local:

# load desired modules
if [ -f /etc/modules.load ]; then
  cat /etc/modules.load | while read module; do 
    modprobe $module
  done
fi

Now you can just create a file /etc/modules.load that contains a list of 
modules, one module per line.




------------------------------

From: "killerlife" <[EMAIL PROTECTED]>
Subject: How i sleep a thread, and doesn't block another thread?
Date: Tue, 22 May 2001 16:44:03 +0800

How i sleep a thread, and doesn't block another thread?
Who can tell me where are i can find the document for pthread?




------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: mmap() and msync() extensions?
Date: Tue, 22 May 2001 08:46:58 +0000

At150bogomips wrote:
> 
> Dragon Cvetkovic <[EMAIL PROTECTED]> wrote:
> >You mean something like madvise(3C)?
> [snip]
> 
> Yes !!! . . . and no.
> 
> That Solaris feature is in some ways more than what I was talking about (being
> able to communicate more information to the kernel) and less--it does not
> indicate how an application can tell the kernel not to immediately truly map
> all of a file into memory.
> 
> (I suppose this is another reason why Solaris is considered worth big-bucks.)
> 
> E.g., suppose one had a database file, it might be nice if one could map the
> whole into virtual memory and let the OS worry about how much real memory
> should be used.  I suspect that mmap() tries to place the entire requested
> region into memory at one time.  Rather, it would be nice if one could simply
> indicate that one wishes to use virtual addresses to handle file access rather
> than a file handle (with kernel buffers).

I believe the kernel already works this way.

When you mmap a file pages should not be loaded
until you access them except from a little
readahead.

> 
> Paul A. Clayton
> just a fool, not in love

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Sharing the virtual address space?
Date: Tue, 22 May 2001 10:50:34 +0000

At150bogomips wrote:
> 
> Karl Heyes <[EMAIL PROTECTED]> wrote:
> >Correct, shared memory would be listed in different page tables.  It sounds
> >like what you are describing is a thread, although the stack which is also in
> >the page table is not shared.
> 
> Well, not exactly sharing page tables (the permissions could be different).  I
> am referring to sharing the address translation.  If the virtual address space
> was shared, translation resources could be shared and virtual caches would not
> have to be flushed at process switches.
> 

I believe you could reduce the number of TLB flushes
that way, but you would create a number of other
possible problems.

Probably you would need a large virtual address space,
64-bit might be enough the first few years, but soon
you would need 128-bit virtual address space.

You will have a problem with the fork() system call,
it has to copy all process data (or simulate it).
The new process expects to have its own copy on the
same logical address. You would then have to do that
using segments instead which is not good. Linux is
designed for a linear memory model, making this
change you would exclude all architectures whithout
segmentation. And on architectures with segmentation
you would remove the applications ability to use
segmentation because it has been reserved for the OS.

You would also create problems with fragmentation.
In the current implementation fragmentation of
physical memory is seldom a problem because allmost
all memory allocations are of the same size. Your
suggestion would lead to problems with fragmentation
of the shared linear address space.

Another problem closely related to fragmentation is
allocation of stacks. You don't know at the time of
allocation how big a stack will grow, if the stack
grows beyond the initially allocated size you might
hit another allocation, in which case you would have
to move the stack to another part of the virtual
address space. I doubt you can do that without a TLB
flush.

You also have to assume some memory model using
both a paged linear address space and segmentation.
I know the i386 architecture, but how much of this
can be done on other architectures. And even if you
can do this on other architectures how much of this
code will be portable?

I also think that it would be hard to remain
compatible with existing userspace programs.

-- 
Kasper Dupont

------------------------------

From: [EMAIL PROTECTED] (SammyTheSnake)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Spambot Fodder - Dont Bother To Read - Thanks
Date: Mon, 21 May 2001 19:58:33 +0100

In article <9e9o15$9pj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:

I don't do baseball...
two strikes and out! ;)

*plonk*

Cheers & God bless
SammyTheSnake
-- 
Sam.Penny @ Ntlworld.com                  | Looking for a computer related
Linux, Hardware & Juggling specialist :-) | job, if you can help, e-mail me :)
Wheels: bike, 'ickle bike, and unicycle.  | /o \/ Working on 5 ball 1/2 shower
Boxen: K6-266@300, dual Celery500 & Nx486 | \__/\  & some 6 / 7 ball exercises

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: unresolved symbol: open_namei
Date: Tue, 22 May 2001 10:59:22 +0000

Sumithra Ramanathan wrote:
> 
> Hello
> 
> I recently upgraded to Redhat 7.1 and recompiled a ethernet device
> driver on it. There were no compile time errors. I tried to insmod and
> the error unresolved symbol: open_namei is reported.
> 
> I had the same driver working on Redhat 7.0 and gcc downgraded to 2.95.
> 
> My questions are
> 1. Do I have to downgrade to egcs 1.1.2? If so what are packages to be
> downgraded?
> 2. What does this error mean and why is open_namei not exported?
> 
> Thanks for any suggestions
> Sumithra

>From RH7.0 to RH7.1 the kernel was upgraded from
version 2.2.16 to 2.4.x. There are lots of differences
between the two versions, in particular large part of
the virtual file system and the network layers have
been rewritten.

You have to upgrade the network driver to a 2.4.x
compatible version. It might be possible to downgrade
the kernel, but I think that would be a very bad idea.

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Time to read the Disk
Date: Tue, 22 May 2001 11:16:47 +0000

Joern Engel wrote:
> 
> Hi!
> 
> > Reordering can be done by the kernel or the
> > hardware, but only if the disk accesses are
> > asynchronous. When a program writes data it
> > doesn't have to know if it is asynchronous
> > or synchronous. But in this case it is read
> > accesses which can only be done asynchronous
> > if the application is written to handle it.
> >
> > Doing asynchronous reads is an optimization
> > not being done by the compiler, it has to be
> > done by the programmer. It wouldn't be
> > posible for the compiler to make this kind
> > of optimization reliable.
> 
> I am not sure, if I understand you correctly. You seem to imply that
> internal reordering of the read requests would result in reordered delivery
> of the results.
> 

No, I don't imply that. Of course there can be
a queue in the OS or in the hardware in which
reordering can take place.

But this situation is different, reordering can
not take place for the simple reason that there
is never more than one request in the queue at
the same time.

The application will not put the next request
into the queue before the current has been
completed. And of course neither OS nor
hardware can reorder a request that has not yet
been made.

In the case of write requests the buffer can be
copied, and the application can be told that
the request has been completed. That cannot be
done in the case of read requests, because the
application would then rely on the contents of
memory.

Of course the OS can try to be smart, and
indeed it does. You can try to guess the next
request, and read it in advance. The only
sensible guess is the next block. (Next block
on disk or next block in file depending on the
situation.)

The OS could also protect the page from
reading and allow the application to continue
execution. In case the application does try to
read the page it would have to wait for the
read to complete. In some cases this might
improve performance, but I think the cases
would be rare. Either the application reads
sequential, in which case readahead would be
more appropriate. Otherwise it reads in some
unpredictable order, which might very well
depend on data in which case the application
have to see the data before puting the next
request.

If you actually want the mechanism with
protected page you can get it by mmaping the
file you want to access. (I don't think it is
possible to mmap a device, though it would
indeed make sense to do so.)

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.development.apps
Subject: Re: Newbie programmer
Date: Tue, 22 May 2001 11:21:40 +0000

Nix wrote:
> 
> [Followup-To: overridden, I do not take that group]
> 
> On Wed, 16 May 2001, Thorsten Roggendorf said:
> > xemacs is a frontend for emacs
> 
> I don't know *where* you got that from.
> 
> XEmacs is a fork of GNU Emacs, not a frontend of any kind; there are
> substantial differences between them, but more similarities than
> differences. Which to use is a religious matter. :)
> 

I have always wondered about that X in XEmacs.
I mean Emacs does run under X, so why make a
new version and call that XEmacs?

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: make modules does not work
Date: Tue, 22 May 2001 11:28:09 +0000

Heinz Ruffieux wrote:
> 
> Hi,
> 
> Today I rebuilded my 2.4.2 Kernel (RH7.1) with make xconfig, make clean and
> make bzImage. This worked.
> Then I tried to make modules. It did'nt work and I got the following output
> (last few lines):
> 
[...]

You actually seem to have forgotten "make dep"
before "make bzImage", at least that is worth
trying.

Otherwise it looks like a problem with module
symbol version numbering. That has cause lots
of problems on RH7.0. I have sometimes been
able to solve some problems by changing this
option in xconfig, and deleting all .ver files
in the sourcetree. (And a single .h file, but
I don't remember its name.)

-- 
Kasper Dupont

------------------------------

From: "Hugin" <[EMAIL PROTECTED]>
Subject: Win NT boot and Lilo boot
Date: Tue, 22 May 2001 14:40:45 +0200

Hello,

I've got a Win2000 install on a 90GB Raid array on a Promise
FastTrak100 controller. To boot of this I have to set my BIOS to
boot SCSI first. I also have a linux install on a 9GB harddisk
connected as secondary master. To boot of this I have to set
the BIOS to boot C first.

Is there a way (either by using Lilo or NT loader) so that I can
choose which OS to use during boot?

The problem is that Lilo can't see the raid array, as it is not supported
under Linux. Also tried to add a line to boot.ini and created a
bootsect.lnx file on the raid array which points to the linux unstall,
but had no luck so far...

Suggestions?


Thanks!





------------------------------

From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: Trouble using large amount of memory with Redhat 7
Date: Tue, 22 May 2001 14:16:12 +0100

In article <9ecmlg$5vj$[EMAIL PROTECTED]>, "J. P. Montgomery"
<[EMAIL PROTECTED]> wrote:


> Certainly, the BIOS recognizes the memory ... at least it checks it.  When
> using the non-SMP kernel, top and free (and other ways to indicate memory)
> all indicate that I have 1.5G of memory and 2G of swap.  Clearly, there is a
> memory detection issue with the SMP kernel ... but then this is the only
> time I've ever booted into this kernel ...  

The problem is the interfaces to the BIOS.  A similar sort of thing happened
with hard disk size detection, although linux bypassed the BIOS in that case. 

The main thing I was noting here
> was that the f90 program acquired up to 2G rather than just the 1365 by the
> non-SMP kernel.  Of course, when I checked the limits using ulimit, the
> memory and file parameters were set at 4G ... so why wouldn't the f90
> program acquire close to 3.5 G (the 1.5G ram and the 2G  swap - minus any
> locked memory)?

Again the physical memory (actual RAM) is different from VM.   VM size is
always the same for each process.  ie you could have 100 processes taking
up 1 Gig of VM space and only have 128Meg of RAM, you just be hitting swap
harder.

The reason you don't get 4Gig for each process is that there is also the
kernel involved.  There all sorts of different patches that are not part of
the syandard kernel which allow the VM system deal with large process spaces.

> Incidently, when I run the SMP at home on my dual PPRO with 128 ram and 128
> swap ... and the same kernel ... everything works as expected and the
> results are the same for both the f77 and f90 versions of the test code.  Of
> course, 128M is a far cry from 1.5 G.

Again BIOS different so the memory detection may work.  Is it the same
version of the compilers.  I don't use fortran myself so I don't known the
history the the compilers.

> What parameters (other than the normal ones that the shell commands give me
> access to) should I be looking for if I recompile the kernel (which I
> haven't done in quite a while ...)

One thing I didn't mention for the memory detection issue is that you can
supply parameters to the kernel that can override the memory detection value

eg from lilo

linux mem=XXXM 

karl.

------------------------------

From: NortonNg <[EMAIL PROTECTED]>
Subject: looking for simple sleep func. in kernel
Date: Tue, 22 May 2001 13:47:20 +0000 (UTC)

hi all,

    I try to slower my PC to evaluate network performance. For some reason,
i can't use NIST evaluation. I try to modify the sch_tbf.c to achieve my
requirment. I try to delay the kernel processing by sleep kernel for some
micro second. but, which kernel function i should use?? 
can anyone show me a simple one?


Regards,
jkng

------------------------------

From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Subject: Re: How i sleep a thread, and doesn't block another thread?
Date: Tue, 22 May 2001 16:19:37 +0200


"killerlife" <[EMAIL PROTECTED]> wrote in message
news:9ed9j4$3nk$[EMAIL PROTECTED]...
> How i sleep a thread, and doesn't block another thread?
> Who can tell me where are i can find the document for pthread?
Is there a reason why sleep(.) usleep(.) shouldnt work?




------------------------------

From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Too many open files
Date: Tue, 22 May 2001 17:58:07 +0200

Hi,

I have a strange problem when reading files:

Here a short sniped of source:

  do{
      // Try to open the directory
      ACE_DEBUG((LM_DEBUG,"Try to open directory %s\n",
                 FileDirectory.c_str()));
      DirHandle = opendir(FileDirectory.c_str());

      if(!DirHandle){
          ACE_DEBUG((LM_DEBUG, "Could not open %s:%s\n",
                     FileDirectory.c_str(),
                     strerror(errno)));
          // Sleep a second before retry
          sleep(1);
      }
      

  } while( !DirHandle );

The problem now is as follows:
DirHandle is sometimes NULL and errno resolves to "Too many open files".
As you can see I retry to open the file after some time.
The reason is to use this time to check the number of open
files.
> cat /proc/sys/fs/file-nr
725     26      8192                      
As you can see, even the process limit of 1024 files is not reached
and there are 26 available file handles. 

When unloading some other files in a parallel running thread
the open will be sucessful. But obvious the limit cannot be the
number of file handles. What other limit could this be?
(I checked /proc/sys/fs/inode-nr  and inode-max as well).

Any ideas?

-Arne

------------------------------

From: Julien Laganier <[EMAIL PROTECTED]>
Subject: Write a module
Date: Tue, 22 May 2001 18:00:52 +0200
Reply-To: [EMAIL PROTECTED]

Hi folks,

I have to write a module for the linux kernel. What are the required
functions to implement, and the parameters, like #define, #include, etc.
?
I know int __init(void), void __exit(void), is there any others ?

Kind regards.

------------------------------

From: Julien Laganier <[EMAIL PROTECTED]>
Subject: Write a module
Date: Tue, 22 May 2001 17:58:59 +0200
Reply-To: [EMAIL PROTECTED]

Hi folks,

I have to write a module for the linux kernel. What are the required
functions to implement, and the parameters, like #define, #include, etc.
?
I know int __init(void), void __exit(void), is there any others ?

Thanks.

------------------------------

From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Crypto API/filesystems
Date: Tue, 22 May 2001 17:01:11 +0100

Patched my kernel (2.4.3 with XFS patches) for the crypto stuff so I
can have a loopback encrypted filesystem. No problems with that
and the kernel looks to be working fine.

Next step is the patched losetup and mount. The patches left in
Documenation/crypto are for util-linux-2.10b which is sort of
ancient and does not patch cleanly against any of the range of
versions that I have tried from ftp.kernel.org (well mirror of).
Version 2.10b is not available.

Anyone any idea where I can get some suitable patches for a recent
version of util-linux so I can finish setting up my crypto filesystem?

JAB.

-- 
Jonathan A. Buzzard                 Email: [EMAIL PROTECTED]
Northumberland, United Kingdom.       Tel: +44(0)1661-832195

------------------------------


** 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
******************************

Reply via email to