- 11 Mar, 2010 11 commits
-
-
Mike Galbraith authored
Our preemption model relies too heavily on sleeper fairness to disable it without dire consequences. Remove the feature, and save a branch or two. Signed-off-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1268301520.6785.40.camel@marge.simson.net> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Mike Galbraith authored
This feature hasn't been enabled in a long time, remove effectively dead code. Signed-off-by:
-
Mike Galbraith authored
Don't bother with selection when the current cpu is idle. Recent load balancing changes also make it no longer necessary to check wake_affine() success before returning the selected sibling, so we now always use it. Signed-off-by:
-
Mike Galbraith authored
Allow LAST_BUDDY to kick in sooner, improving cache utilization as soon as a second buddy pair arrives on scene. The cost is latency starting to climb sooner, the tbenefit for tbench 8 on my Q6600 box is ~2%. No detrimental effects noted in normal idesktop usage. Signed-off-by:
-
Mike Galbraith authored
Now that we no longer depend on the clock being updated prior to enqueueing on migratory wakeup, we can clean up a bit, placing calls to update_rq_clock() exactly where they are needed, ie on enqueue, dequeue and schedule events. In the case of a freshly enqueued task immediately preempting, we can skip the update during preemption, as the clock was just updated by the enqueue event. We also save an unneeded call during a migratory wakeup by not updating the previous runqueue, where update_curr() won't be invoked. Signed-off-by:
-
Mike Galbraith authored
Both avg_overlap and avg_wakeup had an inherent problem in that their accuracy was detrimentally affected by cross-cpu wakeups, this because we are missing the necessary call to update_curr(). This can't be fixed without increasing overhead in our already too fat fastpath. Additionally, with recent load balancing changes making us prefer to place tasks in an idle cache domain (which is good for compute bound loads), communicating tasks suffer when a sync wakeup, which would enable affine placement, is turned into a non-sync wakeup by SYNC_LESS. With one task on the runqueue, wake_affine() rejects the affine wakeup request, leaving the unfortunate where placed, taking frequent cache misses. Remove it, and recover some fastpath cycles. Signed-off-by:
-
Mike Galbraith authored
Testing the load which led to this heuristic (nfs4 kbuild) shows that it has outlived it's usefullness. With intervening load balancing changes, I cannot see any difference with/without, so recover there fastpath cycles. Signed-off-by:
-
Mike Galbraith authored
Entering nohz code on every micro-idle is costing ~10% throughput for netperf TCP_RR when scheduling cross-cpu. Rate limiting entry fixes this, but raises ticks a bit. On my Q6600, an idle box goes from ~85 interrupts/sec to 128. The higher the context switch rate, the more nohz entry costs. With this patch and some cycle recovery patches in my tree, max cross cpu context switch rate is improved by ~16%, a large portion of which of which is this ratelimiting. Signed-off-by:
-
Lucas De Marchi authored
Put all statistic fields of sched_entity in one struct, sched_statistics, and embed it into sched_entity. This change allows to memset the sched_statistics to 0 when needed (for instance when forking), avoiding bugs of non initialized fields. Signed-off-by:
Lucas De Marchi <lucas.de.marchi@gmail.com> Signed-off-by:
-
Peter Zijlstra authored
Since pick_next_highest_task_rt() already iterates all the cgroups and is really only interested in tasks, skip over the !task entries. Reported-by:
Dhaval Giani <dhaval.giani@gmail.com> Signed-off-by:
-
Dan Carpenter authored
We haven't used the "orig_rq" variable since 055a0086 "Fix/add missing update_rq_clock() calls" Signed-off-by:
Dan Carpenter <error27@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Cc: efault@gmx.de LKML-Reference: <20100306111752.GL4958@bicker> Signed-off-by:
-
- 02 Mar, 2010 1 commit
-
-
Dimitri Sivanich authored
On UV systems, the TSC is not synchronized across blades. The sched_clock_cpu() function is returning values that can go backwards (I've seen as much as 8 seconds) when switching between cpus. As each cpu comes up, early_init_intel() will currently set the sched_clock_stable flag true. When mark_tsc_unstable() runs, it clears the flag, but this only occurs once (the first time a cpu comes up whose TSC is not synchronized with cpu 0). After this, early_init_intel() will set the flag again as the next cpu comes up. Only set sched_clock_stable if tsc has not been marked unstable. Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Acked-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by:
-
- 01 Mar, 2010 28 commits
-
-
Linus Torvalds authored
Merge branch 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci * 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: (40 commits) DaVinci DM365: Adding support for SPI EEPROM DaVinci DM365: Adding DM365 SPI support DaVinci DM355: Modifications to DM355 SPI support DaVinci: SPI: Adding header file for SPI support. davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table() DaVinci: DM365: Voice codec support for the DM365 SoC davinci: clock: let clk->set_rate function sleep Add SDA and SCL pin numbers to i2c platform data davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 davinci: build list of unused EDMA events dynamically davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case davinci: Keep count of channel controllers on a platform davinci: Correct return value of edma_alloc_channel api davinci: add CDCE949 support on DM6467 EVM davinci: add support for CDCE949 clock synthesizer davinci: da850/omap-l138 EVM: register for suspend support davinci: da850/omap-l138: add support for SoC suspend davinci: add power management support DaVinci: DM365: Changing default queue for DM365. ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: (38 commits) sata_via: Delay on vt6420 when starting ATAPI DMA write ata: Detect Delkin Devices compact flash pata_efar: Enable parallel scanning pata_atiixp: enable parallel scan [libata] pata_atiixp: add locking for parallel scanning [libata] pata_efar: add locking for parallel scanning libata: Pass host flags into the pci helper [libata] pata_marvell: CONFIG_AHCI is really CONFIG_SATA_AHCI libata: Allow pata_legacy to be built on non-ISA but PCI systems pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards [libata] pata_at91: fix backslash-continued string pata_via: store UDMA masks in via_isa_bridges table pata_via: fix address setup timings underlocking pata_serverworks: fix error message pata_serverworks: fix PIO setup for the second channel pata_efar: fix secondary port support pata_cypress: fix PIO timings underclocking pata_cs5535: use correct values for PIO1 and PIO2 data timings pata_cmd64x: remove unused definitions ...
-
Bart Hartgers authored
When writing a disc on certain lite-on dvd-writers (also rebadged as optiarc/LG/...) connected to a vt6420, the ATAPI CDB ends up in the datastream and on the disc, causing silent corruption. Delaying between sending the CDB and starting DMA seems to prevent this. I do not know if there are burners that do not suffer from this, but the patch should be safe for those as well. There are many reports of this issue, but AFAICT no solution was found before. For example: http://lkml.indiana.edu/hypermail/linux/kernel/0802.3/0561.htmlSigned-off-by:
Bart Hartgers <bart.hartgers@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Ben Gardner authored
I have a Delkin Devices compact flash card that isn't being recognized using the SATA/PATA drivers. The card is recognized and works with the deprecated ATA drivers. The error I am seeing is: ata1.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0) I tracked it down to ata_id_is_cfa() in include/linux/ata.h. The Delkin card has id[0] set to 0x844a and id[83] set to 0. This isn't what the kernel expects and is probably incorrect. The simplest work-around is to add a check for 0x844a to ata_id_is_cfa(). Signed-off-by:
Ben Gardner <gardner.ben@gmail.com> Signed-off-by:
-
Alan Cox authored
Again originally proposed by Bartlomiej but this does it by using the generic helper logic instead. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Alan Cox authored
This was originally proposed by Bartlomiej but as a device specific expansion of the init_one function rather than making the helper more generic. Enable the parallel scan via the generic flags. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
This is similar change as commit 60c3be38 for ata_piix host driver and while pata_atiixp doesn't enable parallel scan yet the race could probably also be triggered by requesting re-scanning of both ports at the same time using SCSI sysfs interface. [Ported to current tree without other patch dependancies by Alan Cox] Original is Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> This one is Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Add clearing of UDMA enable bit also for PIO modes and then add extra locking for parallel scanning. This is similar change as commit 60c3be38 for ata_piix host driver and while pata_efar doesn't enable parallel scan yet the race could probably also be triggered by requesting re-scanning of both ports at the same time using SCSI sysfs interface. [Ported to current kernel without other patch dependancies by Alan Cox] Original is Signed-off-by:
-
Alan Cox authored
This allows parallel scan and the like to be set without having to stop using the existing full helper functions. This patch merely adds the argument and fixes up the callers. It doesn't undo the special cases already in the tree or add any new parallel callers. Signed-off-by:
-
Christoph Egger authored
The marvell driver comtains a fallback to ahci for the sata ports which is incorrectly checked as CONFIG_AHCI while the only AHCI config item is actually called SATA_AHCI (which also sounds sensible considering it's a fallback for the sata ports). Signed-off-by:
Christoph Egger <siccegge@stud.informatik.uni-erlangen.de> Signed-off-by:
-
Alan Cox authored
This is needed for some unsupported hardware setups on strange 64bit mainboards where crazy stuff has been done like putting flash ata adapters on the LPC bus, or where the real hardware is hidden/confused. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
PDC2026x chipsets need the same treatment as PDC20246 one. This is completely untested but will hopefully fix UDMA issues that people have been reporting against pata_pdc202xx_old for the last couple of years. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
On Monday 04 January 2010 02:30:24 pm Russell King wrote: > Found the problem - getting rid of the read of the alt status register > after the command has been written fixes the UDMA CRC errors on write: > > @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct > ata_taskfile *tf) > DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command); > > iowrite8(tf->command, ap->ioaddr.command_addr); > - ata_sff_pause(ap); > + ndelay(400); > +// ata_sff_pause(ap); > } > EXPORT_SYMBOL_GPL(ata_sff_exec_command); > > > This rather makes sense. The PDC20247 handles the UDMA part of the > protocol. It has no way to tell the PDC20246 to wait while it suspends > UDMA, so that a normal register access can take place - the 246 ploughs > on with the register access without any regard to the state of the 247. > > If the drive immediately starts the UDMA protocol after a write to the > command register (as it probably will for the DMA WRITE command), then > we'll be accessing the taskfile in the middle of the UDMA setup, which > can't be good. It's certainly a violation of the ATA specs. Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets. Debugged-by:Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Jeff Garzik authored
Noticed and rough patch by Joe Perches. Signed-off-by: -
Bartlomiej Zolnierkiewicz authored
* store UDMA masks in via_isa_bridges[] and while at it make "flags" field to be u8 instead of u16 * convert the driver to use UDMA masks from via_isa_bridges[] * remove no longer needed VIA_UDMA* defines Make some minor documentation and CodingStyle fixes while at it. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Correct via_do_set_mode() documentation while at it. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Timing registers should be programmed with the desired number of clocks minus one clock. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
There shouldn't be any problems with it as IDE cs5535 host driver has been using those values for years and they match values given in the (publicly available) datasheet. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
s/ARTIM2/ARTTIM23/ in cmd648_bmdma_stop() while at it Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Clear the primary channel pending interrupt bit instead of the reserved one. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Account for the requirements of the DMA mode currently used by the pair device. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Fix incorrect handling of recovery clocks value == 16 resulting in overclocked recovery timings & potentially underclocked active timings. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Use standard cycle timing for CFA PIO5 and PIO6 modes. Based on commit 74638c84 for IDE subsystem. Signed-off-by:
-
Bart Hartgers authored
Before only the timings for master were set. Datasheet can be found here: ftp://ftp.vtbridge.org/Docs/Storage/DS_VT6421A_100_CCPL.PDF Surprisingly, a slave drive works without this patch. According to the datasheet, the controller by default derives the DMA mode from the Set Features command issued to a drive. Not sure about the PIO timings, though. The real problem is that the timings for the master effectively are the ones tuned for the slave. If these support different UDMA-settings, there is trouble, especially when the slave supports a higher UDMA than the master. Anyhow, using the same mechanism for both master and slave seems like a good idea. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
