<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Kernel driver lock down processor in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668071#M797591</link>
    <description>Probably its possible. Problem would be that the OS is pretty good at deciding what happens on what CPU and this plan would defeat that.&lt;BR /&gt;&lt;BR /&gt;I'm pretty sure you'd have to write it yourself.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
    <pubDate>Wed, 09 Nov 2005 14:13:38 GMT</pubDate>
    <dc:creator>Steven E. Protter</dc:creator>
    <dc:date>2005-11-09T14:13:38Z</dc:date>
    <item>
      <title>Kernel driver lock down processor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668070#M797590</link>
      <description>On hpux 11i v1 (11.11) is it possible to have&lt;BR /&gt;a given kernel driver for a PCI card only execute&lt;BR /&gt;on one CPU in an SMP system?  Is there a system&lt;BR /&gt;call into the kernel that can affect the scheduler to only execute this drivers kernel threads  (ISR and/or user context) on a given CPU in an SMP system?</description>
      <pubDate>Wed, 09 Nov 2005 13:40:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668070#M797590</guid>
      <dc:creator>Jon Ashburn</dc:creator>
      <dc:date>2005-11-09T13:40:06Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel driver lock down processor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668071#M797591</link>
      <description>Probably its possible. Problem would be that the OS is pretty good at deciding what happens on what CPU and this plan would defeat that.&lt;BR /&gt;&lt;BR /&gt;I'm pretty sure you'd have to write it yourself.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Wed, 09 Nov 2005 14:13:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668071#M797591</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2005-11-09T14:13:38Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel driver lock down processor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668072#M797592</link>
      <description>My belief is that this is possible with psets, but I have never tried it.  The logic is that if the interrupts occur frequently enough it is best to keep the context on a single CPU to take advantage of the processors cache.  Check it out at:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=PSETS" target="_blank"&gt;http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=PSETS&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Or also check &lt;A href="http://www.docs.hp.com" target="_blank"&gt;www.docs.hp.com&lt;/A&gt; for psets.</description>
      <pubDate>Thu, 10 Nov 2005 10:26:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668072#M797592</guid>
      <dc:creator>Ted Buis</dc:creator>
      <dc:date>2005-11-10T10:26:16Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel driver lock down processor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668073#M797593</link>
      <description>From &lt;A href="http://docs.hp.com/en/5185-4322/5185-4322.pdf" target="_blank"&gt;http://docs.hp.com/en/5185-4322/5185-4322.pdf&lt;/A&gt; :&lt;BR /&gt;&lt;BR /&gt;"Real time applications expect somewhat deterministic responses or workload completion times, and hence want zero-to-minimal interference from other running applications in the system. In the past, there was no way to achieve this, so customers set up separate systems for real-time applications. With processor sets, however, customers can now use a single system to achieve the same objectives. Within the system, they can configure a processor set with the required number of processors and bind only the real-time application to that&lt;BR /&gt;processor set."</description>
      <pubDate>Thu, 10 Nov 2005 10:30:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668073#M797593</guid>
      <dc:creator>Ted Buis</dc:creator>
      <dc:date>2005-11-10T10:30:20Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel driver lock down processor</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668074#M797594</link>
      <description>Robert F. Sauers addresses using psets with interrupts in his book "HP-UX 11i Tuning and Performance" on pages 188-189.</description>
      <pubDate>Thu, 10 Nov 2005 10:35:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-driver-lock-down-processor/m-p/3668074#M797594</guid>
      <dc:creator>Ted Buis</dc:creator>
      <dc:date>2005-11-10T10:35:43Z</dc:date>
    </item>
  </channel>
</rss>

