[PATCH] cs46xx: once again SMP fixes, new aproach

[PATCH] cs46xx: once again SMP fixes, new aproach

[Benny Sjostrand]

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

Hi!

This was hard nut break with good solution, with this solution I can 
only find two issues:
1 - for the moment I'm totally convinced that it's a excelent solution -;)
2- as I dont have any SMP machine (yet) I cant test it, untested code is 
 condemned to fail.

I will try to explain my theory, this diagram shows the SCB tree 
structure  in overview:

  FGTaskTree
      ¦
      |
+-----------------+              +-----------------+
| TimingMasterSCB |---next_scb-- |   WriteBackSCB  |--nextSCB ... (misc 
functionality)
+-----------------+              +-----------------+
        |                                |
    sub_list_ptr               (sub tree used for capture)
        |                               ...
+-----------------+  
| CodecOutSCB     |--nullSCB
+-----------------+        
        |
    sub_list_ptr
        |
+-----------------+  
| MasterMixSCB    |--nullSCB
+-----------------+        
        |
    sub_list_ptr
        |
+-----------------+             +-----------------+           
+-----------------+
| SRCTask_SPDIF   |---nextSCB---| SRCTask_SCB0    |--nextSCB--| 
SRCTask_SCB1    |- ... (etc)
+-----------------+             +-----------------+           
+-----------------+
        |                              
|                                    |
    sub_list_ptr                  sub_list_ptr                           
sub_list_ptr
        |                              
|                                      |
+-----------------+              +------------+         
+-----------+       +-----------+         +-----------+
| AsynchFGRxSCB   |              | PCMReader1 |-nextSCB-| 
PCMReader2|       | PCMReader3|-nextSCB-| PCMReader4|-nextSCB- ... (etc)
+-----------------+              +------------+         
+-----------+       +-----------+         +-----------+
        |                              |                      
|                   |                     |
     nullSCB                        nullSCB                  
nullSCB            nullSCB              nullSCB

(i hope you have a wide terminal and fixed font width)

- The pcm_link/unlink only access SCB under it's related SRCTask_SCB*, 
it only touches the nex_scb_ptr, parent_ptr and sub_list_ptr on 
SRCTask.. so it can safely be running paralel with any other 
simultaneous operation on other parts of the tree, and it can be running 
paralell with others pcm_link/unlink related to other SRCTask*.

- In create_pcm_channel the channel is initially created unlinked, which 
mean pcm_link must be called before playback start, invoked by 
playback_trigger. Anyway pcm_unlink was called in playback_open, which 
now can be removed. In this way the pcm_reader SCB will be initially 
floating, with no parent SCB and therefor we dont need any spin_lock in 
create_pcm_channel.

- But, the _same_ PCM stream, playback_trigger cant run before  
playback_open has completed. Which make no sense,  I supose the ALSA PCM 
core prevent a process from doing this to happen.

- In pcm_link the PCMReaderSCB is always linked in after SRCTask* 
sub_list_ptr, then therefor is no need loop searching for the last free 
SCB in sublist.

Conclusion what we got is:
- No mutexes in playback_trigger
- Independent spin_locks for each SRCTask*
- spin_lock only needed in pcm_link/unlink and in cs46xx_dsp_remove_scb.

With fewer and short spin_locks, theorically we manage to have good 
performance on SMP machines -:)

That's all, ... i think ...
Question, suggestion or whatever you got in mind about this is welcome, 
i'll try to be open.

/Benny

[-- Attachment #2: cs46xx_patch --]
[-- Type: application/x-java-vm, Size: 34089 bytes --]

Re: [PATCH] cs46xx: once again SMP fixes, new aproach

[Takashi Iwai]

At Thu, 22 Aug 2002 23:29:20 +0200,
Benny Sjostrand wrote:
> 
> 
> - The pcm_link/unlink only access SCB under it's related SRCTask_SCB*, 
> it only touches the nex_scb_ptr, parent_ptr and sub_list_ptr on 
> SRCTask.. so it can safely be running paralel with any other 
> simultaneous operation on other parts of the tree, and it can be running 
> paralell with others pcm_link/unlink related to other SRCTask*.
> 
> - In create_pcm_channel the channel is initially created unlinked, which 
> mean pcm_link must be called before playback start, invoked by 
> playback_trigger. Anyway pcm_unlink was called in playback_open, which 
> now can be removed. In this way the pcm_reader SCB will be initially 
> floating, with no parent SCB and therefor we dont need any spin_lock in 
> create_pcm_channel.
> 
> - But, the _same_ PCM stream, playback_trigger cant run before  
> playback_open has completed. Which make no sense,  I supose the ALSA PCM 
> core prevent a process from doing this to happen.
 
this must be ok.

> - In pcm_link the PCMReaderSCB is always linked in after SRCTask* 
> sub_list_ptr, then therefor is no need loop searching for the last free 
> SCB in sublist.
 
good, that's somewhat i thought of.

> Conclusion what we got is:
> - No mutexes in playback_trigger
> - Independent spin_locks for each SRCTask*
> - spin_lock only needed in pcm_link/unlink and in cs46xx_dsp_remove_scb.
 
great!
the patch looks more cleaner than before.

> With fewer and short spin_locks, theorically we manage to have good 
> performance on SMP machines -:)
> 
> That's all, ... i think ...
> Question, suggestion or whatever you got in mind about this is welcome, 
> i'll try to be open.

i'll try to run and merge to cvs later.


thanks!


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390