Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVM delay does not work in the middle of program execution #26

Open
Bongss opened this issue Aug 23, 2018 · 3 comments
Open

NVM delay does not work in the middle of program execution #26

Bongss opened this issue Aug 23, 2018 · 3 comments

Comments

@Bongss
Copy link

Bongss commented Aug 23, 2018

Hello

I have some problem with NVM read delay.

In my case, as the size of the data increases, it seems that the NVM read delay does not work in the middle of program execution. but if the data size is small, it works well.

I attached the picture that I captured the part where delay did not work using debug mode.

image

What should I do?

I look forward to your reply

My Experiment setup

  • Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz (2 socket)
  • Linux Kernel : 4.4.0-31-generic
  • Ubuntu 14.04.5 LTS
  • RAM : 256GB
@hadibrais
Copy link
Contributor

In all of the instances you highlighted, the stall cycles is zero. The Quartz PM model does not inject any delay if the stall cycles is zero. This is in general one of the flaws in the model because even if the stall cycles is zero, a delay might need to be injected nonetheless. But it is not a bug; it's by design.

@seojiwon
Copy link

Is it not possible that some bugs might cause the zero stall cycle? Because in our experiment, it is not possible for the stall cycle to be zero because we do a lot of random memory access. When the overall data size in the data structure is not large (700MB) we don't observe this oddity; we only see this behavior (0 stall cycle and 0 delay cycle) when we test with larger data size (> 1.5GB), and we observe this in a burst.
Is it not possible that as the number of data items in a data structure increases, the overall memory access increases, hence there might be some overflows inside quartz?

@guimagalhaes
Copy link
Collaborator

In order to verify if there were stalls, the emulator needs to perform performance counter reads.
The model is then calculating the ammount of cycles to be injected: the performance counters are read and the calculations are performed. These calculations take several cycles to be executed and the model attempts to account as the overhead by decreasing the overhead cycles from the cycles to be really injected. In your scenario, the overhead is taking more cycles than it is needed to be injected. So, the emulator is not injecting anything.
Please check if the architecture/OS is acting to hide stalls by using large pages or if really random access is being performed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants