public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed

From: "Ilya Lipovsky" <lipovsky@cs•bu.edu>
To: <linuxppc-embedded@ozlabs•org>
Subject: Huge page support for PowerPC 32 bit and WIMG flexibility
Date: Wed, 31 Jan 2007 17:01:34 -0500	[thread overview]
Message-ID: <000b01c74583$7166e6f0$3a0d10ac@Radstone.Local> (raw)

[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

Hi,

 

I am not experienced in kernel development, so please be patient.

 

After exploring the latest (2.19.2) sources it appears that there is no huge
page support for the 32 bit powerpc platform. I deduced it by starting from
0x300 in head_32.S and comparing notes with head_64.S. It appears that the
only sensible path for hashing in a huge page (on 64bit ppc) is via:

 

0x300: data_access -> do_hash_page -> hash_page -> hash_huge_page

 

Unfortunately, on the 32bit, all paths that do anything useful end up in
create_hpte() found in hash_low_32.S. I noticed someone on this mailing list
claiming huge page support for IBM 44x core. Is it possible to make it
general enough to encompass ppc32 in general?

 

Another issue I have is the absence of control over hardware specific
attributes of memory such as WIMG. More concretely, I am interested in
having the ability to allocate off the heap in such a way so as to
explicitly set the M (coherency) bit off (independently of SMP or non-SMP
mode). This is needed because some multicore PowerPC platforms (e.g. 745x)
perform an extra address broadcast to guarantee cache coherency per each
store miss on a cacheline. This degrades performance for store-bound
programs.

 

I understand that hashing pages as non-cache-coherent makes data contained
therein a potential victim to cache coherency paradoxes. Nevertheless, since
I am working on high performance library, I am prepared to shift coherency
guarantees to the library, which is supposed the one managing the data flow
between memory and CPU caches intelligently.

 

So, I have 2 main questions:

 

1)       What's so special about ppc32 that it didn't get the matching
feature of huge page support that ppc64 has? Who is responsible/willing to
fix it?

2)       Is it appropriate to provide a syscall mechanism (parallel to
sys_brk, sys_mmap, and sys_shmget) to add WIMG settings?

 

Overall, the vision here is to be able (from user-side, on powerpc32) to
call:

 

shmid = shmget(2, LENGTH, SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W |
POWERPC_NONCOHERENT);

shmaddr = shmat(shmid, ADDR, SHMAT_FLAGS);

 

And get a segment mapped with wimg=0bxx0x (actually, I assume all x's are
0). This would be very nice!

 

 

Thank you,

-Ilya

 

P.S. As a side note, it is pretty difficult to read kernel sources
(especially assembly ones) because of the lack of comments for people who
are not in the kernel hacker "circle." For example, what in the whole world
is "paca??"


[-- Attachment #2: Type: text/html, Size: 9069 bytes --]

next             reply	other threads:[~2007-01-31 22:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-31 22:01 Ilya Lipovsky [this message]
2007-01-31 22:29 ` Huge page support for PowerPC 32 bit and WIMG flexibility Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000b01c74583$7166e6f0$3a0d10ac@Radstone.Local' \
    --to=lipovsky@cs$(echo .)bu.edu \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox