Proposed new kernel noncaching memory allocator for the 405gp

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:

quoted

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/

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/

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:

quoted

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/

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/

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/

Ralph Blach wrote:

David Blythe wrote:

quoted

I think something more general then pci_alloc_consistent would be

better

quoted

for devices that are not pci based.  We are still working on getting a

quoted

pci OHCI usb to work with the walnut card and are running into a lot

of

quoted

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 [off-list ref]
MontaVista Software, Inc

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

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/

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:

quoted

quoted

David Blythe wrote:

quoted

quoted

I think something more general then pci_alloc_consistent would be

better

quoted

for devices that are not pci based.  We are still working on getting a

quoted

pci OHCI usb to work with the walnut card and are running into a lot

of

quoted

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 [off-list ref]
MontaVista Software, Inc

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


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

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:

quoted

Ralph Blach wrote:

quoted

quoted

David Blythe wrote:

quoted

quoted

I think something more general then pci_alloc_consistent would be

better

quoted

for devices that are not pci based.  We are still working on getting a

quoted

pci OHCI usb to work with the walnut card and are running into a lot

of

quoted

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 [off-list ref]
MontaVista Software, Inc

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

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/

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:

quoted

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.

quoted

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/

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/