[Differential] [Commented On] D3034: Add BUS_UNMASK_INTR method

[onwahe-gmail-com (Svatopluk Kraus)]

onwahe-gmail-com added a comment.

In https://reviews.freebsd.org/D3034#61087, @wma_semihalf.com wrote:

> I guess treating PPIs are separate IRQs number will cause a huge mess. I'm starting to port fbsd on 96 core armv8 platform and the idea of  1536 vectors wasted for PPIs is outrageous.


In fact, PPIs are separate interrupts. So if you have 96 core armv8 platform with 16 PPIs on each core, then you have 1536 PPIs. If you have 96 core, then you have probably enough memory to run them all. And I certainly will not call using of 1536 IRQ numbers as wasting in this case. Moreover, 1536 IRQ numbers are allocated only if all of them are used.

Further, with such many cores, I can imagine more than before that same PPI could be served differently on various subsets of cores. However, I do not say that it's necessary to have an IRQ number for each PPI on each core. I just say that it should be so in principle. It could be optimalized according to usage.

Think about PPI statistics for example. Will be PPI interrupts counted on a single counter? (Just do not forget to use atomic increment in that case. I have confirmed that even two cores count badly without atomics.)

Anyhow, I still think that problem with PPIs you desribed can be dealt with either in nexus or in interrupt framework without a need to change bus interface. (You can change the way how bus_setup_intr() and bus_teardown_intr() are implemented for PPI kind of interrupts.)

> My point in adding separate interface is to support multi-PIC systems. Calling BUS_UNMASK_INTR with an appropriate resource will allow to pick up the correct PIC controller in a generic way (as I looked into intrng last time it was capable of associating device with specific PIC).  Adding the same code to timer driver might be really inelegant, thus  require  a static map either in the driver or in intr_machdep file.


Note that only root PIC is capable of PPIs and SGIs (IPIs).

However, if you really want to add some new bus interface, I would like to know more about it. For example, what about to add man pages for it? What about to add bus_mask_intr() too? What is difference between it and  bus_activate_resource()? What about to add cpuset_t argument to it? (Which, I believe, was Michal's point for using with SPI.) Must be ensured that no cpu migration happens during the call? I have a really bad feeling with the change how it's introduced now.

> > The proposed bus_unmask_intr() cannot be used from outside of secondary CPUs startup context. It cannot be used for SPI, it cannot be used of PPI after scheduler is started on given core.

> 

> 

> Actually, I'm not quite sure I understand your point.  Why cannot one use it for SPI (except it might not have a sense) or what the scheduler has to do with PPI? The only risk I see (in current implementation) is that someone calls unmask when irq is not configured. 

>  The freebsd also lacks the fine-grained interrupt blocking mechanism, like, for example, mask/unmask pair exported as bus interface (that would require adding mask call here also). I bet if you ever tried to write a driver for some queer  and exotic piece of hardware  you wished these functions existed, like in other OSes. Or at least I have...





REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D3034

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: wma_semihalf.com, emaste, imp, ian, andrew, zbb
Cc: onwahe-gmail-com, freebsd-arm-list, meloun-miracle-cz, imp, andrew, emaste