• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Locking pages in physical memory for real-time processes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking pages in physical memory for real-time processes


  • Subject: Re: Locking pages in physical memory for real-time processes
  • From: David Duncan <email@hidden>
  • Date: Thu, 6 May 2004 19:15:51 -0400

On May 6, 2004, at 03:42 PM, Doug Wyatt wrote:
But this does lead us to a more common and important issue to be aware of -- taking VM faults on the render thread when your code or data is paged *in*.

There is a way in Shark to trigger samples on VM faults, and then view only the faults that happened on the render thread. I can dig up the details if someone else doesn't find it first.

It is one of the standard profiles in Shark. There are VM Faults Time, Page In, Copy on Write, and Zero Fill profiles. Shark is very cool.

--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.

David Duncan
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.


References: 
 >Locking pages in physical memory for real-time processes (From: Stéphane Letz <email@hidden>)
 >Re: Locking pages in physical memory for real-time processes (From: David Duncan <email@hidden>)
 >Re: Locking pages in physical memory for real-time processes (From: Doug Wyatt <email@hidden>)

  • Prev by Date: Re: Locking pages in physical memory for real-time processes
  • Next by Date: New QT possibly breaks 3DMixer OpenAL
  • Previous by thread: Re: Locking pages in physical memory for real-time processes
  • Next by thread: Re: Locking pages in physical memory for real-time processes
  • Index(es):
    • Date
    • Thread