Proposed new kernel noncaching memory allocator for the 405gp

Proposed new kernel noncaching memory allocator for the 405gp

[Ralph Blach]

David,

This is what I propose,

I propose a kmalloc_noncache and a kfree_noncached.

These would be module and would be loaded when necessary.  They would
operate allocating say 16k (could be any size)  of memory during boot
time
and then mapping it non cached.  The the kmalloc_noncached routine would

carve out little chucks of it and the free routine would release it.  It

would also have a noncached to real routine
to return the real address of a noncached section.

Does this sound interesting?

Chip




David Blythe wrote:

> Ralph Blach wrote:
> >
> > David,
> >
> > Do you have USB working from on OHCI pci card?
> >
> > Would a kmalloc_nocache and kfree_cache be useful to you?
> >
> > Chip
> >
> >
>
> I think something more general then pci_alloc_consistent would be
better
> for devices that are not pci based.  We are still working on getting a

> pci OHCI usb to work with the walnut card and are running into a lot
of
> cache coherency problems.
>         david

--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina



--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Dan Malek]

Ralph Blach wrote:

> I propose a kmalloc_noncache and a kfree_noncached.
>
> These would be module and would be loaded when necessary.  They would
> operate allocating say 16k (could be any size)  of memory during boot
> time
> and then mapping it non cached.


That's a simplistic start, but not the right implementation.  It
should be a clone of kmalloc/kfree that will dynamically allocate
and free pages when necessary.  I've implemented the simplistic
version of these functions specifically for the MPC8xx CPM and
associated drivers, just copy those and use them if you want.

You have to carefully trade off using uncached memory against the
cache management (flush, invalidate, etc.) functions.  Using uncached
memory is a significant performance loss, and I know the USB is
already implemented to use cached memory and the management functions.
This works on all of the existing processor architectures, so there
isn't any reason to go back and change it.

Why don't you just go ahead and write and test these functions and
submit them as a patch against a recent kernel?  That would be much
more useful than just suggesting things and being upset when the
rest of us don't implement them because we have higher priority projects
to work on.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Ralph Blach]

Dan,

I forsee using these for
Descriptors that must be read and written by the processor and need atomic
updating.
Using these in the OHCI driver would greatly simply the driver because the
TD would not be cached.
Data should always be flushed and never allocated no-cache.

Where are these functions that you say you have implemented?

Chip

Dan Malek wrote:

> Ralph Blach wrote:
>
> > I propose a kmalloc_noncache and a kfree_noncached.
> >
> > These would be module and would be loaded when necessary.  They would
> > operate allocating say 16k (could be any size)  of memory during boot
> > time
> > and then mapping it non cached.
>
> That's a simplistic start, but not the right implementation.  It
> should be a clone of kmalloc/kfree that will dynamically allocate
> and free pages when necessary.  I've implemented the simplistic
> version of these functions specifically for the MPC8xx CPM and
> associated drivers, just copy those and use them if you want.
>
> You have to carefully trade off using uncached memory against the
> cache management (flush, invalidate, etc.) functions.  Using uncached
> memory is a significant performance loss, and I know the USB is
> already implemented to use cached memory and the management functions.
> This works on all of the existing processor architectures, so there
> isn't any reason to go back and change it.
>
> Why don't you just go ahead and write and test these functions and
> submit them as a patch against a recent kernel?  That would be much
> more useful than just suggesting things and being upset when the
> rest of us don't implement them because we have higher priority projects
> to work on.
>
>         -- Dan

--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Dan Malek]

Ralph Blach wrote:

> Using these in the OHCI driver would greatly simply the driver because the
> TD would not be cached.

I'm not sure that is for us to decide.  I don't really want to
know that much detail about USB, and the experts that ported these
drivers to processors without cache coherent DMA requested the
functions as you see them now.  If they decide they want something
different, we'll provide those.  The IBM4xx is a late-comer to
the issues of ensuring cache coherency, and all we are doing is
adopting existing functions that standard Linux software has been
using on other platforms.


> Where are these functions that you say you have implemented?

arch/ppc/8xx_io/commproc.c allocates one (or more) pages of memory
during early initialization, marks them uncached, and will allocate
a few bytes for some drivers.  I think only the uart driver uses
this right now for allocating its DMA FIFOs.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Kernel Dumps

[Brad Bonkoski]

Hello all,

Is there a good FAQ or HOWTO for reading kernel dumps?
Thanks,
Brad


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Kernel Dumps

[Wolfgang Denk]

In message <3ABB5A4C.F1CA6987@mcg.mot.com> Brad Bonkoski wrote:
>
> Is there a good FAQ or HOWTO for reading kernel dumps?

You mean, in addition to /usr/src/linux/Documentation/oops-tracing.txt ?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offence.
          -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Frank Rowand]

Ralph Blach wrote:
>


>
> David Blythe wrote:


> > I think something more general then pci_alloc_consistent would be
> better
> > for devices that are not pci based.  We are still working on getting a
>
> > pci OHCI usb to work with the walnut card and are running into a lot
> of
> > cache coherency problems.


Dan Malek has provided the functions consistent_alloc(), consistent_free(),
and consistent_sync() for uses other than PCI.  They are in linuxppc_2_5
rev 1.446 and later (I'm not sure if they are in any earlier version).
They are also in my active development kernel, but not yet in any kernel
that I have put on my ftp site.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Dan Malek]

Frank Rowand wrote:

> Dan Malek has provided the functions consistent_alloc(), consistent_free(),
> and consistent_sync() for uses other than PCI.

But, what I haven't yet done is modify the general PowerPC PCI
functions (like pci_consistent_alloc()) to use these lower level
functions on the MPC8xx or the IBM4xx.  If you want to hack those
PCI functions in your local sources, go ahead, as the plan is to
make those work.  I just have to test against other platforms to
ensure I didn't break something, which is much more time consuming
that just making them work for a specific test environment.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Ralph Blach]

Frank,

Yes, but these allocate on a page boundry and I was thinking of something a
little more granular.

Any objections?

Chip

Frank Rowand wrote:

> Ralph Blach wrote:
> >
>
> >
> > David Blythe wrote:
>
> > > I think something more general then pci_alloc_consistent would be
> > better
> > > for devices that are not pci based.  We are still working on getting a
> >
> > > pci OHCI usb to work with the walnut card and are running into a lot
> > of
> > > cache coherency problems.
>
> Dan Malek has provided the functions consistent_alloc(), consistent_free(),
> and consistent_sync() for uses other than PCI.  They are in linuxppc_2_5
> rev 1.446 and later (I'm not sure if they are in any earlier version).
> They are also in my active development kernel, but not yet in any kernel
> that I have put on my ftp site.
>
> -Frank
> --
> Frank Rowand <frank_rowand@mvista.com>
> MontaVista Software, Inc

--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Frank Rowand]

Ralph Blach wrote:
>
> Frank,
>
> Yes, but these allocate on a page boundry and I was thinking of something a
> little more granular.
>
> Any objections?
>
> Chip
>
> Frank Rowand wrote:
>
> > Ralph Blach wrote:
> > >
> >
> > >
> > > David Blythe wrote:
> >
> > > > I think something more general then pci_alloc_consistent would be
> > > better
> > > > for devices that are not pci based.  We are still working on getting a
> > >
> > > > pci OHCI usb to work with the walnut card and are running into a lot
> > > of
> > > > cache coherency problems.
> >
> > Dan Malek has provided the functions consistent_alloc(), consistent_free(),
> > and consistent_sync() for uses other than PCI.  They are in linuxppc_2_5
> > rev 1.446 and later (I'm not sure if they are in any earlier version).
> > They are also in my active development kernel, but not yet in any kernel
> > that I have put on my ftp site.

Nope, but this sounds like a generic kernel issue to me, not a PowerPC issue.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Dan Malek]

Ralph Blach wrote:

> Yes, but these allocate on a page boundry and I was thinking of something a
> little more granular.

You can only control cache behavior on page boundaries at best, and
from the few drivers I have looked at, this is exactly what they
expect.

> Any objections?

I have been listing them in previous messages.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[acmay]

On Thu, Mar 22, 2001 at 04:23:44PM -0500, Dan Malek wrote:
>
> Ralph Blach wrote:
>
> > Yes, but these allocate on a page boundry and I was thinking of something a
> > little more granular.
>
> You can only control cache behavior on page boundaries at best, and
> from the few drivers I have looked at, this is exactly what they
> expect.

In the ppc405_enet driver both the Tx & Rx Desc Tables need to be
4kb aligned but only 130 bytes of the 2 pages are used. The max
the chip will even try to use is around 1k of the 8k.

If other chips don't need the 4k alignment requirement for their
data it would be a win to provide uncached mem from the same 2
pages needed for the enet chip.

--
Andrew May

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Ralph Blach]

Dan,

No, the transmit descriptors in the USB  code are much less than a page.  Look
at ohci-usb.c
Why do a kmalloc?  And what about SCSI and it linked list?  These need bytes and
not whole pages.



Any I'll do it and submitt it .

Chip

Dan Malek wrote:

> Ralph Blach wrote:
>
> > Yes, but these allocate on a page boundry and I was thinking of something a
> > little more granular.
>
> You can only control cache behavior on page boundaries at best, and
> from the few drivers I have looked at, this is exactly what they
> expect.
>
> > Any objections?
>
> I have been listing them in previous messages.
>
>         -- Dan

--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[Brad Parker]

Ralph Blach wrote:
>
>Frank,
>
>Yes, but these allocate on a page boundry and I was thinking of something a
>little more granular.
>
>Any objections?

There's a some of work going in this are on the linux usb list - check
out the recent archive.

Apparently the holy grain is the slab allocator which will allocate
non-cached memory.  There are several drivers (scsi & usb) which have
their own private versions.  Work is going on to create a generic library
which all drivers (pci and otherwise) can use...

-brad


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Proposed new kernel noncaching memory allocator for the 405gp

[andrew may]

On Thu, Mar 22, 2001 at 11:24:02AM -0800, Frank Rowand wrote:
> Dan Malek has provided the functions consistent_alloc(), consistent_free(),
> and consistent_sync() for uses other than PCI.  They are in linuxppc_2_5
> rev 1.446 and later (I'm not sure if they are in any earlier version).
> They are also in my active development kernel, but not yet in any kernel
> that I have put on my ftp site.

They are in the 405Gp kernel date Mar 1 on the ftp site.

If they are for things other than PCI they should use virt_to_phys
instead of virt_to_bus. On the 405gp this works since pci_dram_offset
is set to 0.

--
Andrew May

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/