headers
tabris | 1 Jun 2004 01:24

Re: [LKML]kmalloc -contiguous locations ?


On Monday 31 May 2004 5:49 am, Shobhit Mathur wrote:
> Hello,
>
> I would like to know whether kmalloc() guarantees
> virtually contiguous memory locations ?
> Is there a limit on the amount of contiguous memory
> that can be returned by kmalloc() ?
	First, kmalloc returns physically contiguous memory.
	second, the limit (on x86) is 128kb (32 pages), allocatable in powers of two 
pages. (1,2,4,8,16,32. often called 0-order thru 5-order allocations)

	vmalloc returns virtual contiguous allocations, with no guarantee on physical 
contiguity. The problem with vmalloc, iirc, is that there's a [total] limit 
of 128MB for vmallocs.

	Also remember that all kernel memory allocated with vmalloc() or kmalloc() is 
non-swappable.

	I don't know how this changes under any other architecture, such as x86-64 or 
PPC32/64.
>
> - Thank you
>
> - Shobhit Mathur

--
tabris
-
	A master was explaining the nature of Tao to one of his novices.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernd Eckenfels | 1 Jun 2004 01:30
Picon

Re: why swap at all?

In article <40BBB5F7.1010407 <at> yahoo.com.au> you wrote:
> Well, at the "expense" of paging out unused memory. I don't see
> any swapin.

On a slow system with small memory you quite often see swapped out
applications like for example a kopete messenger windows. Once you click on
it, it takes 10sec or more to get responsive again. Of course its a slow
system, but gradually paging out and forgetting image pages has that effecct
on faster systems too, makes the desktop sluggish.

> Well yes, but if I had another 57MB of physical memory then I would
> still turn on swap so that other 57MB of unused memory isn't wasted.

Actually the number of totally unused memory is quite small. Therefore the
pages get swapped in sooner or later anyway. And even if you turn of fswap
completely, the image pages backed up by binaries on disk get still freeded,
if the code is unused. So on my multimedia system I prefer to have no swap
(1GB ram) and make sure the pages are not freeded so aggressivley to keep
the system smooth and responsive (and allow spin down of the disk).

Bernd
--

-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Permalink | Reply | 34 comments |
headers
Benjamin Herrenschmidt | 1 Jun 2004 01:52

Re: misc device suspend/resume new model

On Tue, 2004-06-01 at 08:57, Florian Lohoff wrote:
> Hi,
> what is the preferred way of getting suspend/resume events (new model)
> with misc devices registered via misc_register.
> 
> Registering a sys_driver/device/class ?

The suspend/resume events aren't propagated from the functional
interface/class (which misc is), but from the bus binding. So you
should get them from whatever bus your device is on, that is via
a pci_dev for PCI devices, etc...

Ben.
Permalink | Reply | 0 comments |
headers
Maurice Volaski | 1 Jun 2004 02:03
Favicon

Re: tg3 module in kernel 2.6.5 panics

>Maurice Volaski wrote:
>>The tg3 module in (gentoo) kernel 2.6.5 panics on boot on a 
>>dual-opteron 248 box with 4G RAM. I copied the following screen 
>>output...
>
>
>This looks like kobject stuff unrelated to tg3.
>
>Does 2.6.6 fail similarly?
>
>	Jeff

So do 2.6.7-rc1 and rc2.
--

-- 

Maurice Volaski, mvolaski <at> aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
Permalink | Reply | 0 comments |
headers
Neil Brown | 1 Jun 2004 02:52
X-Face
Picon
Picon
Favicon

Re: nfsd readahead

On Monday May 31, colin <at> gibbsonline.net wrote:
> Hi,
> 
> I was having problems with slow streaming reads over nfs. After much
> investigation, I found that nfsd uses its own cache of readahead
> parameters and that:
> (1) they were not being reused
> (2) they were not being initialized properly

Thanks a lot Colin. (I did get your earlier person email, but it
didn't get to the top of the priority queue until today).

The current code is a bit of a mess isn't it!!!

I have one question about your patch:

> +	file_ra_state_init(&ra->p_ra, file->f_mapping);

I note that the corresponding code in fs/open.c(dentry_open) reads

	file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);

i.e. there is an extra level of indirection.  Is there a reason that
you didn't copy that.

I am seriously thinking of getting rid of the "open_private_file"
stuff, and using dentry_open to open files for nfsd, and just allow it
to init the ra_state, so that nfsd doesn't do it itself.
However that patch touches 13 files, so I want to see it get a bit of
testing first.
(Continue reading)

Permalink | Reply | 1 comment |
headers
ndiamond | 1 Jun 2004 02:38

Re: How to use floating point in a module?

In http://www.ussg.iu.edu/hypermail/linux/kernel/0405.3/1620.html,
Linus Torvalds wrote:

> You can do it "safely" on x86 using
> kernel_fpu_begin();
> ...
> kernel_fpu_end();
> and make sure that _all_ the FP stuff is in between those two things, and 
> that you don't do _anything_ that might fault or sleep.

In http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/1591.html,
Alan Cox two years ago advised another questioner that init_fpu()
could be called after kernel_fpu_begin().  Looking at the source code,
this seems like a good idea.

Since the kernel is 2.4. 20something, init_fpu() takes no arguments.

I am looking at directory linux/arch/i386/kernel, with file i387.c
containing functions kernel_fpu_begin() and init_fpu() and others,
file i387.o resulting from a compilation, and Makefile saying that
i387 is included in the obj-y list.  So it seems to me that the executing
kernel should have kernel_fpu_begin() and init_fpu() built in.

But when we do insmod on our module, the list of undefined symbols
includes kernel_fpu_begin and init_fpu.  How is this possible?

(The CPU is an i686.  I'll have to look up its opcodes and see if its
hardware will come close enough for everything the driver needs.  If it
doesn't, I'll buy one of the books that some others kindly recommended
and do polynomial approximations.)  (By the way the driver is being
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phy Prabab | 1 Jun 2004 03:37
Picon
Favicon

NFS performance 2.4.21 vs 2.6.7-rc2

Cross posting to NFS list as well.

Hello,

I have been doing some testing of NFS performance with
2.4.21 and 2.6.7-rc2 (2.6.5 and 2.6.6 as well).  I
have noticed that 2.4.21 seems to be faster with the
same hardware and mount options as noted by iozone
(iozone -s 1g -r 1m -o).  As well, the amount of CPU
power on the server side is higher for the test run
under 2.6.7-rc2.  Is this known, or have I done
something incorrect?

2.4.21:

1048576    1024   46646   60697   814945   845351 
844893   24716  845657  106998  845220    44423   
60731  811409   841193

2.6.7-rc2:
1048576    1024   42944   48703   536023   546492 
543524   23445  537662   83739  544263   188456  
259651  538667   537420

I have run the same test against NetApp filers and two
different linux file server (2.4.22 and 2.6.7-rc2). 
The client is a 2x 3.0GHz w/8G RAM, Ge (tg3).

Thank you for your time.
Phy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Gibbs | 1 Jun 2004 04:01

Re: nfsd readahead

On Mon, 2004-05-31 at 18:52, Neil Brown wrote:

> Thanks a lot Colin. (I did get your earlier person email, but it
> didn't get to the top of the priority queue until today).

Well I sent it to the nfs list first (it seems to have been eaten by
some moderation queue) and forgot I also sent it to you.

> The current code is a bit of a mess isn't it!!!
> 
> I have one question about your patch:
> 
> > +	file_ra_state_init(&ra->p_ra, file->f_mapping);
> 
> I note that the corresponding code in fs/open.c(dentry_open) reads
> 
> 	file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);
> 
> i.e. there is an extra level of indirection.  Is there a reason that
> you didn't copy that.

Looks like that was in a patch after 2.6.6. Another good reason to avoid
duplicate code paths. 

> I am seriously thinking of getting rid of the "open_private_file"
> stuff, and using dentry_open to open files for nfsd, and just allow it
> to init the ra_state, so that nfsd doesn't do it itself.
> However that patch touches 13 files, so I want to see it get a bit of
> testing first.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard B. Johnson | 1 Jun 2004 04:11

Re: How to use floating point in a module?

On Sun, 30 May 2004 ndiamond <at> despammed.com wrote:

> A driver, implemented as a module, must do some floating-point
> computations including trig functions.  Fortunately the architecture
> is x86.  A few hundred kilograms of searching (almost a ton of searching :-) seems to reveal the following possibilities.
>

Since you are using one of those Windows mailers and didn't enter a
single end-of-line character, I detect that this is probably one
of those trolls. Nevertheless, the use of floating-point is forbidden
within the kernel. Period. Because anybody who thinks they need
floating-point mathematics within the kernel is completely without
a clue, the floating-point context is not saved/restored during system
calls.

You must pair a user-mode program (usually called a daemon) with
the kernel-mode interface to your hardware (your module). This
combination will provide whatever functionality you require. The
user-mode daemon does the math and probably a lot of other things
as well.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5583.66 BogoMips).
            Note 96.31% of all statistics are fiction.
Permalink | Reply | 0 comments |
headers
ndiamond | 1 Jun 2004 04:27

Re: How to use floating point in a module?

Richard Johnson makes another enemy:

> Since you are using one of those
> Windows mailers and didn't enter a
> single end-of-line character,

The web-based mailer that I used for
submitting these behaves the same for
all Windows mailers including X11
Konqueror, X11 whatever Red Hat's
latest browser is, and XP IE.

> I detect that this is probably one
> of those trolls.

Good detective work.  I guess you were
looking in a mirror.

> Nevertheless, the use of floating-
> point is forbidden within the kernel.

That's why my first posting proposed a
method of getting the necessary results
without using floating-point hardware,
and my third posting reminded another
non-reader that my first posting said
what it said.

But then someone named Linus something-
or-other posted a reply saying that it
(Continue reading)

Permalink | Reply | 0 comments |

Gmane