Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24

[Karsten Wiese]

Am Mittwoch, 29. Juni 2005 21:38 schrieb Ingo Molnar:
> 
> * Karsten Wiese <annabellesgarden@xxxxxxxx> wrote:
> 
> > attached patch for io_apic.c lets
> > 1. gcc 3.4.3 optimize io_apic access a little better.
> > 2. CONFIG_X86_UP_IOAPIC_FAST work here.
> >    Didn't check, if it really speeds up things.
> 
> which change made CONFIG_X86_UP_IOAPIC_FAST work on your box? It seems 
> you've changed the per-register frontside read-cache to something else - 
> was that on purpose?
> 
CONFIG_X86_UP_IOAPIC_FAST started working here, when I made io_apic_modify()
look like that:

void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val)
{
#ifdef IOAPIC_CACHE
	io_apic_cache[apic][reg] = val;
#endif
//	if (unlikely(sis_apic_bug))
commented this ^^ out 

		*IO_APIC_BASE(apic) = reg;
	*(IO_APIC_BASE(apic)+4) = val;
#ifndef IOAPIC_POSTFLUSH
	if (unlikely(sis_apic_bug))
#endif
		/*
		 * Force POST flush by reading:
 		 */
		val = *(IO_APIC_BASE(apic)+4);
}

This change does it, 'cause when we read a cached value instead of from the ioapic,
the ioapic's address register isn't set and thus the following write in io_apic_modify
might not scratch the right ioapic register.

On top of the above the patch adds
	unsigned int reg;
to io_apic_cache.
with that "reg" struct member a mark -1 can be set, when we read from cache,
or the reg-number, when we read from the ioapic.
Then by comparing parameter reg with io_apic_cache[apic].reg
the patched io_apic_modify() knows, if it has to set the address register or not.
The register caching in the patch should be the same as before,
only the cache changed from a 2 dimensional array
to an array holding structs, which contain an array:
io_apic_cache[apic][reg] should be equivalent to io_apic_cache[apic].val[reg], no?

Karsten




	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/